Recently Blog Entries
- Why Your Kanban Workflow Should Be More Than “In Progress”
- Two Questions to Help You Understand if You’re Doing Kanban
- Spike Abuse
- My Latest Article on Agile and Security
- Essentials of the Scaled Agile Framework
- A Possible Solution to the Issue of Test Data
- Project Sauron: A Long-lived, Stealthy and Likely State-sponsored Malware
- CCTV cameras used in massive botnet
- Sprint Planning: The Case for Finishing What You Start
- Scrum Retrospectives: Start, Stop… Continue? One of these things is not like the others…
Subscribe
RSS
Categories
Polls
Loading ...
Archives
- May 2017
- April 2017
- September 2016
- August 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- January 2016
- December 2015
- October 2015
- September 2015
- July 2014
- January 2014
- March 2013
- February 2013
- January 2013
- December 2012
- July 2012
- May 2012
- April 2012
- January 2012
- November 2011
- October 2011
- September 2011
- August 2011
- April 2011
- October 2010
- August 2010
- July 2010
- June 2010
- May 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- September 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
Admin
Search
Oct
14
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.
Comments
5 Comments »
Blogroll
- Ars Technica
- Dark Reading - IT Security
- Help Net Security
- InformIT
- SANS Internet Storm Center
- Schneier on Security - Dr. Bruce Schieier’s blog
- Security Info Watch
- What to Fix - Daniel Markham, fellow consultant
- Wired Gadget Lab
- Wordpress Documentation
- WordPress Planet
- Wordpress Support Forum
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
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
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?
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
[…] Temptations of an Agile Project: Too Many Stories […]