Hi Richard,
My Scrum team has been working on a particular service for over a year. It’s been 20+ Sprints. I’m concerned about the deliverables and the rate at which we deliver. I have just put together some material for my stakeholders. I am pasting those slides here for your review. Do you mind reviewing them and letting me know what you think? That would be very helpful.
We have completed 20+ sprints. Our average velocity is 36 story points. High being 81 and low being 3. Do you see such up and down in velocity to this extent?
Every sprint we have many stories slipping over to next Sprint. Here’s a line graph between stories that are delivered in 1 sprint vs stories that took more than one sprint. I read somewhere that it is ok to slip a story to next sprint, but if this becomes a practice, I am a bit worried. Is this normal across other teams and is this agreeable?
Our overall ratio of multi-sprint stories is close to 50%. That means almost half the stories that we pick have slipped over.
Story age as I calculated is the time taken to complete a story. From the time it is picked up (not from the time the story was written) to the time it is delivered. Please see below. Is this ok? Or is this way odd compared to other teams that use Scrum.
What are your thoughts on this situation? If it’s undesirable, what should we do to fix it?
Thanks,
Samuel (@samueldarwin)
—
Samuel,
Thanks for the note. Lots of teams struggle with this, but I’ve never seen one with such great data about their behavior.
Why Long-Running Stories Are a Problem
You’re right to be concerned about stories taking longer than a sprint. Long-running stories
- Delay value
- Delay and reduce opportunities for feedback
- Provide room for work to expand to include low-value things instead of focusing on the core value
- Can lead to stories growing beyond the investment they’re worth
What Causes Stories to Run Over?
There are two common causes for these long-running stories:
- The stories are too big, or
- Too many stories are being worked on in parallel
It looks like you’ve done 132 stories over 20 sprints, assuming the charts all cover the same time period. That’s an average of 6.6 stories per sprint.
My rule of thumb is 6-10 stories per sprint—enough that you’re not spending too much of your velocity on any one story but not so many that you waste lots of time splitting and tracking them.
You’re right on the edge of the stories being too big, especially if there’s much variation in size between them. That is, your larger stories could probably benefit from splitting.
I suspect the second cause of long-running stories, however, is a more important issue for you. Your team members probably all work on their own stories most of the time, starting all the stories at the beginning of a sprint, and getting most of the partly done by the end. Your daily stand-up meetings are probably full of people saying, “I’m still working on X. No impediments.”
How to Fix It
There are two ways to change this, the direct way and the indirect way.
The Direct Approach
The direct approach is to decide as a team to explicitly limit work in progress, or WIP. You might agree on a WIP limit of, say, 3 stories in progress. Thus, if 3 stories are already started, someone looking for work to do needs to find a way to contribute to one of those rather than starting a new one. Today you’re cumulative flow diagram probably looks something like A in the image below. With a low WIP limit, it would start looking closer to B.
Notice in terms of tasks, as shown on the burndown chart, both A and B are getting the same amount of work done each day, but team B gets *stories* done every couple days. There’s a linear relationship between WIP and cycle time. Starting fewer things gets things done faster.
The Indirect Approach
Your team may protest that it’s inefficient for them to collaborate on stories together. “We’ll just step on each other’s toes,” they say. (For now, we’ll give them the benefit of the doubt and set aside the observable fact that their current approach isn’t getting things done quickly, the very definition of *efficient*.)
The indirect approach, then, has two parts:
- Only commit to as much work as you’ve actually completed in a single sprint. If your CFD looks like team A in the image above, you’d just plan about half as much work in the next sprint.
- If (or, typically, when) you finish early, pull exactly 1 small story. If you finish that early, do it again. Repeat until the sprint is over.
In the first part of the sprint, the team will probably try to work every story simulataneously. But since there’s less work than they’re used to, they’ll have to collaborate a little more than usual. Then, when they finish early and pull a single story from the backlog, they’ll have to experiment with more extreme collaboration. The CFD will end up looking something like this one:
This collaboration will feel less efficient than working in parallel. Every time I’ve seen a team run this experiment, though, they’ve ended up completing more work with the “inefficient” approach than they ever previously finished in a single sprint. There’s nothing like a real experiment to challenge deeply-held assumptions!
Give it a try, and let me know how it turns out.
—
Do you have a question you’d like to see answered on this blog? Contact us.
Last updated