Ask A4A: Long-running Stories

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?

Velocity per Sprint

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?

Completed vs Carried-over Stories per Sprint

Our overall ratio of multi-sprint stories is close to 50%. That means almost half the stories that we pick have slipped over.

Single vs Multi-sprint Stories

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.

Story Cycle Time

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.

Two ways of approaching a sprint. Click to see a larger version.
Two ways of approaching a sprint. Click to see a larger version.

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 simultaneously. 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:

The indirect approach to limiting WIP. Click for a larger version.
The indirect approach to limiting WIP. Click for a larger version.

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.

Update, October 2020: Richard’s latest story splitting resources are available at Humanizing Work.

Related Articles

Responses

  1. Sometimes the developers may still have a waterfall mindset. For example, previously they may have had several requirements for a big new report. However, none of those requirements may address the database design and other groundwork that must occur. However, maybe they previously gave an estimate of 3 months because they knew they needed to include time for the groundwork. Fast forward to Agile. Now they have one or more user stories for this new report. When dev does it’s analysis and realizes there is some prep work that needs to occur ahead of the user stories for the report, a user story or two should be created for that prep work. It should not be larger than what can fit in the sprint. Then the development team has not only a sense of accomplishment at the end of each sprint, but the scrum meeting updates become meaningful, the sponsor team understands what is actually being worked on, and the same user story is not used for multiple sprints!

    1. I would suggest a sprint 0. This is a sprint that contains discovery/prep/architecture work and is 2-4 weeks. It needs to be WELL defined and carefully thought out. At the end of this, you have provided immense value and can start providing even more (that the stakeholders can see) in sprint 1.

  2. While I agree with everything Richard said, I might suggest an earlier step, prior to suggesting story slicing–although that very well might be what is needed.
    The data you gathered is EXCELLENT. You are acting as the mirror to the team, providing information that is empirical and impersonal, and reveals that somehow, the system is not functioning optimally. Your metrics are the gages that prove that the engine is running rough and inefficiently. But WHY is this happening?
    This is the question that the team must address themselves in the retrospective. YES, it is possible the stories are too big. Your “Story Age” graph might suggest that. However, it may NOT. Why are these stories aging so much?
    There are other plausible causes that must be considered and the team must weigh in on this.
    * Is the team being interrupted, or is there constant flux of priorities and direction that causes stories to be set aside until the team can return to them?
    * Are stories stuck due to lack of business engagement, are they waiting for answers, or is there a lack of clarity in the stories?
    * Are stories stuck due to technical reasons that might be solved via dev-ops improvements?
    * Have you looked at the Point estimates and duration? This may throw some agilists into a dither, but this is important. If most of those aging stories had high Fibonacci numbers, then this suggests to Richard’s point that they are not being sliced, or risk is not being properly addressed, etc. But if even smallish stories are aging, this could reveal other problems, such as poor quality story definition (maybe the PO didn’t understand what was really needed, or the team is failing to ask probing questions to understand what is needed–or they are not refining stories at all, in cases where there are no backlog refinement meetings, or ineffective ones.
    * Is the team resistant to story slicing? Are they resistant to swarming? Is the team missing expertise or knowledge, or plagued by knowledge silos, impeding them from working more efficiently?

    I have gathered similar reports and used them to drive the conversation. The key is that the TEAM must be guided to identifying the root causes of the issues, and the TEAM must collaboratively create a plan of action!

    Be sure to solve the right problem. Best of luck!

  3. Hi all,

    This is a very common scenario in Agile ways of working. In my current team the problem was they were hesitant to split the stories which were carried over many sprints. But when they did, we achieved first ever positive trend in the burn down chart. From then on the team understood how important is to split the stories up. It not only helps in finding out what exactly is been done for the particular feature but it give managers a better view of burn down stories.