> Stories (tasks) are the focus of attention; [...] We forget that stories are only a crude approximation of the work needed to finish an initiative; and more importantly, that the work only matters when it has delivered end value.
The fundamental principle of story-based work planning is that the story is an atomic unit of end value; stories may be groups into larger units that represent broader goals or divided into smaller tasks for planning convenience, but the defining aspect of the story is that it is the smallest unit of work providing independent end-value.
It’s true that, especially with Scrum and similar processes with timeboxed work cycles, teams tend to end up using “stories” that aren’t real user stories, but units of work (which may not even have started as real user stories, as instead of reserving a timeslice for support [refactoring, general infrastructure, and other useful for velocity but not directly targeting specific user needs tasks] work, the same disfunction leads teams to arbitrarily declare that all work must be called stories whether or not it is) arbitrarily carved up to fit the cycle timebox and the team’s [or some decision-maker’s] arbitrary preference for the number of work items per cycle.
I would argue that this is because sprints are a software development process antipattern in and of themselves, are particularly in tension with user-story-based work organization, and lower the resistance to a number of other antipatterns of the general description of applying classic top-down non-agile project management within a framework of “agile” buzzwords.
I think this is a result of a lack of granularity in the styles of stories. I worked in a heavy XP shop and we were consistent in ensuring stories were units of value, chores were things that needed to be done to enable the delivery of value, and bugs were just that.
Additionally, we didn’t point bugs and chores because points are supposed to be a measure of delivering value. If you have stories as units of work, your points just became yet another measure of a unit of work.
Also, having worked in the XP shop and a “traditional Agile” shop, we never preplanned sprint work. We worked in one-week iterations as a means of bookkeeping, but we never committed to work ahead of time. We just pulled off the backlog and kept going. Some weeks we’d get more done, some we’d get less, but we had a trend line of velocity that gave us a projection of how much work we’d get done. I don’t actually care much for committed-work sprints as a means of getting work done. It just doesn’t feel useful.
In time boxed sprints it annoys me no end that ONLY stories get pointed and then a “percentage of the sprint” is reserved for unpointed work. Given that points aren’t allowed to equal time and bugs and chores are allowed to be pointed the question becomes “a percentage of what exactly?”
Removing the time bounding makes much more sense as you’ve said above.
I have this argument with my PO and SM - if points don’t equal time then why do we plot points vs time on a burn down?
Not pointing work in this scenario is just a way for management to squeeze extra work in that looks free.
Yep, the conflation of points into time-spent is a perversion of Agile and creates an incorrect metric for value delivered to the user.
If you look at points as a lagging indicator of time estimation, it’s much more valuable as you can establish trends and look at those trends versus team strength, etc. Additionally, if you use the ratio of stories, bugs, and chores as a leading indicator of product/team/codebase health, you can make intelligent decisions about when larger refactors are necessary. If you find yourself spending more and more time on bugs, you might want to take a step back, assess the cause and invest in fixing it.
Basically, getting rid of timeboxing, establishing team SLOs on portion of work (such that breaching your error budget requires refactoring/paying down tech debt/halting delivery of new value), and ensuring points are only assigned to value-producing work, would result in a better process and clearer outcomes and impact.
To me, points should be an estimate of complexity. Higher complexity means more unknowns, more traps, larger possible range of time to complete. If the current codebase is murky, then I add points. I promise that if we fix the murky areas in the code then we can build faster and more predictably.
A 1 pointer means nothing can really go wrong. It's a linear time task.
I don't think the Product Manager digs my philosophical approach.
This is called "kanban" in agile-speak, despite it being basically the inverse of that term's original meaning from production engineering.
And yes, I completely agree that timeboxes are counterproductive. It just takes the least reliable part of software engineering (task size estimation) uses it as the fundamental tool for organization or all activities.
> It’s true that, especially with Scrum and similar processes with timeboxed work cycles, teams tend to end up using “stories” that aren’t real user stories, but units of work
These are called "enabler stories", and they will be a part of any sufficiently large project. The principles of the Agile Manifesto, or any other grand pronouncements about the relationship between developer and user/customer, are not why your company went Agile. Measurability and trackability with respect to OKRs is.
> ”If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” — Antoine de Saint-Exupéry
You know, to yearn for a milestone?
> “Compare that to a narrative that leads with purpose: ‘we want to do THIS THING, so that’s why we think we should do THIS WORK.’ The message is: ‘focus on finishing THIS THING.’”
A thing, which most milestones are, is not a purpose.
If this had said customer outcome, and that the flavor of milestone is that the customer is now empowered to achieve that outcome, I’d be on board.
For me, this essay fails to connect the aspirational quotes or customer purpose with focusing an effort.
> The problem is that teams lose sight of the forest for the trees.
Oh! That's the problem! Silly me. I thought there were multiple problems like:
- rampant micromanagement
- non-devs creating stories for the devs
- "stories" not being used to tell stories
But that's what happens when dev tools (agile) are marketed as dev management tools (Agile). The problem is that the systems meant to get devs closer to customers have been coopted by middle men and now they create distance.
Agile was developed for consulting projects and in that context can be quite powerful. It also offers some insights that can be useful for efforts of a longer and more ambitious scale.
But the wholesale adoption of agile techniques and vocabulary has been a cargo-culting disaster, imho.
1) Everyone. I mean _everyone_ in the organisation needs to commit to the Scrum model. Sales guys aren't excepted from the scrum cycle. If they need a "quick little thing" they put it in the backlog and wait.
2) The Scrum model needs to be adapted to the organisation, it's not a one size fits all model. Most maintenance-style operations don't fit the standard scrum model (ongoing CS issues etc), and testing is kinda iffy (do we test the sprint result during the sprint or during the next sprint?).
I think there may be a chance for success in going FULL scrum, but really there are a couple of caveats.
* The appropriate sprint-length must be found, there is a lower-bound by how long you need for developing something with user-value (i.e. demoable), and upper bound the tolerance of your customer (or sales organisation) to wait until requested features will be implemented. Most scrum teams seem to use 2 week sprints which is typically too short unless you are developing simple products like CRUD applications potentially.
* If we take 1 sprint-length (1 SL) as a basic time unit, then you need to realise that a new, highest-priority feature will on average take 1.5 SLs to delivery if it really is Priority 1.
* teams must really be 90% self-reliant to do everything needed in the sprint. Once you have need to synchronise development across scrum-teams, you loose. basically now value delivery can easily take 2-3 SL OR needs to be carefully planned / aligned for the same sprint ahead of time so you get at a lower-boundary of 2-2.5 SL (> 1.5 SL) for work involving more than one team, easily exploding to 3-4 SLs.
deve
With these considerations, we quickly get into longer-ranges of planning, especially if you are in a multiple-team kind of situation, that you get easily into when you (a) don't have a dev team deploying to the cloud (b) are developing more-complex software systems with multiple components / services developed by several teams.
The elephant in the room of course is that all of this thais not discussed in your Scrum training, because they mostly outline a happy-path for this 8 person team
disclaimer: I prefer Kanban-style sprint-less work mode overall.
Wholeheartedly agree. On our side we are not only multiple dev teams working tightly together on the same product (CAD application in a highly regulated medical field), but we also have a domain experts group, a designer group and the POs that need to prepare the high-level user stories and behavior of the features pre development. Our teams work with 3 week sprints and we found that in order to actually start development of a topic we need ~3SL prep time, meaning POs write high-level user stories, domain experts discuss how the detailed workflow behavior should best be like, then the designers come with mockups. Those are typically not aligned and need several feedback loops until it is settled. Then we devs need to break this down, look into the technical side, groom the tickets, write Dev stories and estimate them. Then the PO prioritizes the tickets and we pick em for the sprint. Then we develop for typically 3 sprints, but sometimes longer. After the pure development come the feedback loops again with the domain experts and the actual stakeholders. This can also take 2-3SL easily. So we have
Post development our deliveries also have to synch with the bi-yearly sales windows of our parent company and need coordination for marketing, regulatory affairs / verification & validation, training & education and the sales team.
The real challenge is to somehow interface our agile development process within a traditional workflow (marketing, T&E, sales needs to know upfront what features will be delivered at a given release some month in advance so they can plan and prepare their activities and materials for a commercially successful software release.
"In too many engineering teams, sprint planning and daily standup are centered on the sprint board and backlog. Stories (tasks) are the focus of attention; discussions are focused on achieving pointing targets, the mechanics of how to achieve a particular task, or dependencies and sequencing. The problem is that teams lose sight of the forest for the trees. We forget that stories are only a crude approximation of the work needed to finish an initiative; and more importantly, that the work only matters when it has delivered end value."
I disagree with the author on the point of standups - they're not big-picture strategic sessions; they're about short-term, tactical planning. What work are you going to do today? Are you blocked by anything?
That's not to say that the big picture should be forgotten, but it's wildly impractical to do an initiative-level review every single day.
> I disagree with the author on the point of standups - they're not big-picture strategic sessions; they're about short-term, tactical planning. What work are you going to do today? Are you blocked by anything?
This has always been my problem with standups: they feel a bit too much like micromanagement.
This may have been due to how your standup worked. Believe me I have seen it too and part of why I want to be a team lead/scrum master is to make sure this does not happen to my team.
Did your standup feel like a report to the Product Owner? Or a report to the Scrum Master? Or a report to Team Lead? Not good. Creates the feeling you had.
The standup should create conversation between team members. 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup'
As a scrum master if they 'report status to you' you can for example not look them in the eyes all the time so that they can't fixate on you. There are ways to still show them that you are paying attention.
If the PO is asking follow-ups that make it clear he's expecting status reports to him you can take him aside and talk to him about that. It might come to the point where you have to threaten to throw him out of standup if he doesn't shut up and then he won't even be able to even listen.
Same goes for team lead depending on whether you have a separate scrum master or maybe the team lead has that hat.
> The standup should create conversation between team members.
A team of even adequate--not great, just adequate--people working together will have these conversations independently.
> 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup'
There are two different cases where this would apply: when someone attempts to do something and finds some blocking issue, and when someone attempts to do a task out-of-order from a dependency.
The first case rarely occurs in a way that a daily standup will efficiently address. Most tasks take longer than a day to do--the standup is unlikely a time when this sort of issue is most efficiently resolved. Other than junior engineers or maybe quick bug fixes I rarely encounter an engineer who measures his work by the time between standups.
The second case is best resolved by having a proper, complete design process--requirements analysis, technical design (changes in architecture, code, dependencies, etc.), and a team-wide review--and a work tracking tool that permits tasks to be ordered (e.g. JIRA's "blocked by" label). Work doesn't always fit into that neat of a design and execution process, obviously, and it's okay to have an occasional, regular meeting (e.g. once a week or every other week, maybe slightly more often depending on the scope of work the team typically has) to address those specific issues as-needed. But those meetings shouldn't be permanently scheduled on the calendar--just while a given project is in progress.
> A team of even adequate--not great, just adequate--people working together will have these conversations independently.
Then the daily standup will be really damn fast. =)
On the other hand the daily is a place where you _know_ that the other person isn't busy and it's a good time to raise any concerns or ask for assistance.
If it's going to be "really damn fast" because nobody has anything (more) to say, it's pointless (and micromanagement, for the managers' benefit only).
And if the person is busy, they should indicate as much. People shouldn't have to have a carve-out on their calendar for concerns or requests for assistance: that's an indication of a dysfunctional team.
My fastest scrums have went like this (on $chat_application):
<scrum master> anyone have anything new for daily?
<dev1> nope, still working on $task
<dev2> nope
<tester1> nope, still finishing up testing $task2
<scrum master> let's skip it then
User stories are a very effective and important tool to separate features while addressing every level technology involved.
Milestones are another tool and booth are valid to use. It always depends on the size and quality of the team that uses the tools.
Blog posts like that are often too superficial to be useful.
It be best to run through real examples, ok, what are your actual milestones about, how did you break them down, what are your actual stories, how do you connect the two, etc.
A common analogy used often, is developers are like soldiers, and the managers are the commanders who are not in the battlefield, so they just tell soldiers what to do but they're not the ones receiving enemy fire (tight deadlines, fixing bugs, etc.). A better analogy to try and model organizations would be that developers are like wizards, and managers are mere non-magic muggles (from Harry P.) that are paying the wizards to do a certain task. Wizards are interested in the contract and will carry it out, but there's no point in a muggle telling a wizard what to do. Of course this varies and some wizards are not yet as high level as others, but the this is effectively inverting that hierarchy where the non-technical people have full control over a project, when they are not the experts.
This sounds preposterous and unorthodox, but it would solve many problems. Of course the technical people at the top would be the ones with the most experience and the ones that have contributed the most code across all layers of the software, and precisely because of that they could easily come up with a high level plan that would work. Then the managers would just take that plan and dress it up for whoever needs to know about it, and also take care of the admin tasks and facilitate meetings. Again, this sounds upside down and something managers will never agree to of course, but every organization I've been in, engineers succeed despite the manager's "orders", not because of it. I'm not saying managers don't offer anything here, but what they do offer is less valuable than the code itself by definition, since that is what gets shipped, yet somehow they are in this "overseer" position (sorry, but it really feels that way), where they are "responsible" but we all know at the end of the day the developers and engineers are truly responsible anyway.
I just want to make nested checklists to keep track of what needs to be done. That anyone on the team can easily change, reorder or delete without anyone in management knowing or caring how or why we chose to put what we put on the checklist.
Management should only care about the results and money. How we organize to get any particular thing done, should be no one else's concern.
> Management should only care about the results and money. How we organize to get any particular thing done, should be no one else's concern.
This is pretty much what scrum is kinda supposed to be when implemented properly. (No True Scrumsman Fallacy =P )
"Management" has a prioritised backlog of items, the team commits to executing one of the top items in an allotted timeframe. During the timeframe "Management" is not allowed to influence the work in any way or change the specifications midway.
If they do, everything done so far is supposed to be scrapped and the timeframe starts from scratch - this clause is there to give an actual measurable cost to messing with the team during a sprint.
The fundamental principle of story-based work planning is that the story is an atomic unit of end value; stories may be groups into larger units that represent broader goals or divided into smaller tasks for planning convenience, but the defining aspect of the story is that it is the smallest unit of work providing independent end-value.
It’s true that, especially with Scrum and similar processes with timeboxed work cycles, teams tend to end up using “stories” that aren’t real user stories, but units of work (which may not even have started as real user stories, as instead of reserving a timeslice for support [refactoring, general infrastructure, and other useful for velocity but not directly targeting specific user needs tasks] work, the same disfunction leads teams to arbitrarily declare that all work must be called stories whether or not it is) arbitrarily carved up to fit the cycle timebox and the team’s [or some decision-maker’s] arbitrary preference for the number of work items per cycle.
I would argue that this is because sprints are a software development process antipattern in and of themselves, are particularly in tension with user-story-based work organization, and lower the resistance to a number of other antipatterns of the general description of applying classic top-down non-agile project management within a framework of “agile” buzzwords.