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

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.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  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!

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches teams and organizations to become happier and more productive. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room.

Connect

richard.lawrence@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author