“Stories” Don’t Tell a Story: Good Sprint Planning Uses Milestones
cgroom.medium.com
cgroom.medium.com
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.
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.
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.
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.
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.
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.
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.
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.
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?).
* 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.
3SL prep | actual implementation ≥ 3SL | 3SL feedback loops & polish
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.
There really aren't any good solutions for that, only bad and worse ones...
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.
This has always been my problem with standups: they feel a bit too much like micromanagement.
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.
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.
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.
Once the time is allocated, if there's nothing of importance to discuss then some low value subject will always fill it.
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.
<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 thenAnd nobody else will know about them.
Milestone might be "Support for ABBA-Lifter Model 2 in mapping system"
Stories would be something like "As a Lifter owner, I want to see where my fleet is located" etc.
After completing all the Stories a Milestone is complete and can be released to customers.
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.
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.
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.
I don't know the business value and sequencing of any of my "good idea faerie" strikes that I put into the backlog.
Grooming the backlog and producing the overall arc of effort needs access to more business information than I am privy.