Temptations of an Agile Project: Too Many Stories

Posted by Keith McMillan

October 14, 2009 | 5 Comments

Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.

We’re going to talk today about the product backlog. For those unfamiliar, the backlog is the list of functions or features that the product owner or business want in the eventual product. On a Scrum project, these are usually user stories, a sentence in what I call “Cohn Normal Form” is:

I as type of user, want to perform some function so I can receive some benefit.

For instance: “I, as a customer of the bank, want to withdraw money from the ATM, so I can buy a cup of coffee.”

User stories come in all kinds of shapes and sizes, from big ones (“I as an insurance agent want to enter a claim for my customer so they can be reimbursed”) to very small (“I as a shopper want to print out a copy of my receipt so I can keep track of my purchases”).  Most teams try to make stories small enough that they can be started and completed in a single iteration or sprint, from requirements through testing and hopefully deployment.

The industry average for the length of a sprint is growing shorter, and it’s not uncommon to see iterations of 2 weeks or even shorter, so big stories need to be decomposed into smaller ones if they’re going to fit within a short sprint.  So far, so good, but this is where the problem comes in.

The problem comes in with the following reasoning

If it’s a good idea to break up stories in the backlog when we’re getting ready to work on them, then it seems like it might be a good idea to make all stories in the backlog small enough to fit, even if you’re not going to work on them for a while.

Why isn’t this a good idea? One reason has to do with prioritization of work.  User stories in the product backlog should be in priority order, from the highest (1) through the least important (“n”, where there are “n” stories in the backlog).  It’s pretty easy to deal with prioritizing a list of 20 items, but much harder once that list gets larger. Consider, for instance, a modest backlog of 120 items. If we discuss the priority of each item for only one minute, it’s going to take us two hours to prioritize the backlog.  Assuming we do actually assign priorities to these items, we’re probably not going to be interested in re prioritizing that list any time soon.  Our backlogs need to be easy to re-prioritize if we’re going to be responsive to business priorities changing.  The same reasoning applies to assigning complexity estimates: the more stories you have to estimate, the more longer it will take.

Another reason to discourage breaking our stories up too soon: it makes it harder to keep track of which ones go together.  Suppose you break a single, large story into 7 smaller ones, and you later decide that the original large story needs to be brought to the top of the priority list. You’re going to have to have some way to find those 7 smaller stories you created in order to move all of them. If you’d kept the one bigger story, that would be a no-brainer.

Finally, if we resist the temptation to break down all our stories immediately, we might avoid some work. This can happen either because priorities change, and stories are withdrawn from the backlog, or because we learn something while working on more important stories that substantially changes later ones.

When should you break large stories down into smaller ones? As late as possible, preferably just as your team undertakes work on them.  If you can avoid breaking your stories into lots of little ones, you’ll have an easier time re-prioritizing and estimating complexity, keeping track of what stories go together, and you might even save some work.


RSS feed | Trackback URI


Comment by Bhardwaj Velamakanni
2009-11-20 22:24:28

We manage the stories in a hierarchical fashion. If a story needs to be broken down, we create multiple child stories so that when the priority of the parent changes, we can easily manage the linked children

Comment by Keith McMillan
2009-11-24 06:58:37

Hi Bhardwaj,

Your approach of using a hierarchical structure to the backlog is one I’ve used as well. Realize what we’ve done, though: now got a backlog consisting of fewer stories (the parent stories), with “notes” in the form of child stories, which is exactly what I’m advocating.

The thing that tends to happen with this approach, though, is that the child stories begin to develop priorities separate from their peers, and you can end up right back where you started from.

Thanks for your comments!

– Keith

Comment by Louis Klein
2009-11-23 15:48:19

How do you deal with product owners who want an idea of ROI as part of the prioritization process? To give them evan a SWAG, it seems to me you need an idea of the IT investment required to develop the feature described. That would indicate a need for enough decomposition into estimateable bites.

Waiting to get a real idea of your development complexity can lead to owner frustration as you have to (if you’re being honest) give him a ‘bigger or smaller than a breadbox” estimate.

Or have I missed something along the way?

Comment by Keith McMillan
2009-11-24 07:04:21

Hi Louis,

I think that getting an idea of complexity, and thus ROI, involves discussing what the product owner wants, and I’ve no objection with creating notes for a story that capture that discussion. I think that teams create headaches when they take that next logical step (breaking the story down) too soon. It makes the backlog unmanageable.

I’ve also found that despite team’s protestations that they need lots of detail to produce relative estimates of complexity, they can actually do it with less detailed information than they think. I worked recently with a very experienced agile practitioner and coach, and he felt strongly we couldn’t size the backlog for a new project without lots more discussion. I asked if we could spend just half an hour trying an affinity estimating exercise, and at the end of 25 minutes we had the sizing done.

Thanks for our comments!

– Keith

2009-12-14 14:10:25

[…] Temptations of an Agile Project: Too Many Stories […]

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.