Stories and Size – What is too large when?
In agile software development, finding the right amount of detail and decomposition with stories takes teams a few iterations, possibly releases, to get comfortable. It is a tough balance – we want the stories to be large enough that our product owner(s) understands what the story is for and the team understands the story contextually, yet we need the work small enough so that we can have confidence in estimating and so that we can get the story flowing through our feedback loop soon. I want to outline briefly how I like to approach this in the hope that it may help some others.
Jeff Patton is one of my favorite people, an overall awesome dude, and his storymapping is such a beautiful tool that I wish more tools would naturally support it. When I am working with companies, I use storymapping as means of helping people not only visualize their product but also as means of helping groups understand where and when to break down work. If you haven’t heard or used storymapping before, please do check out Jeff’s blog posting on it. It’s ok, I will wait.
Cool, thanks for coming back.
When we start planning a product, it is most important for us to ‘go wide instead of deep’ – we want to create a view containing as much functionality of the product as we know right now. Ideally we are binding / validating this work against personas, but in reality that isn’t always the case. However, at this level it doesn’t make the most sense to think of every possible permutation of the work that could be done. If my product was an online retail store, at this level I may say that we need some inventory administration functionality, ways for customers to purchase goods, and maybe some learning of the products we are selling. Those 3 items are large, large stories – call them whatever you want, but there is potentially so much work in them that it doesn’t make sense to stop there, even at a product planning session. I would want more detail to start driving my release planning.
From those three large stories, we would break those down into the next level of detail – how would a user administer inventory? Well, they might need to see current inventory, see rate of sale, look at expected time for more goods, automate the restock process…and so on. Repeat this for the rest of the larger stories, keeping our detail levels pretty consistent. After this, as a product owner, I might be able to pick a subset of these stories and say that subset makes up enough of a product for it to be viable, lets do that. Now the agile development team does relative estimates to give a rough set of expectations (which we will constantly refine).
At this point in the software development process, we have a contextual view of where we are going, have an idea of potential other work coming up in future releases, and have the stories (be it large) for our first release. We enter our first sprint planning session; let’s say we have the following 2 stories are in the sprint: check current inventory for a product, and automate restock process. We do relative estimating across these stories and see that the check current inventory story is a 2 and the automate restock process is a 21 (working in points). Since we value feedback, we are comfortable that the 2 point story is small enough to be deliverable in a portion of an iteration, but the 21 point story is far too large. We retain the original story, but break it down into more stories. To automate the restock process we need to be able to create baselines of when to restock, we need to set up communication channels with one (possibly many) vendors, we need to communicate with accounting for paying, and we need to update inventory when new inventory comes in. We then size these new stories relatively and see what makes sense for our sprint, perhaps pulling 2 of the 4 stories in. The rest go into our backlog. Once we have the stories for our sprint ready, we can do any further task breakdown as needed.
I have a few goals with this approach:
- Never decompose earlier than I have to. That doesn’t mean don’t ask questions; it means don’t get too far ahead of ourselves. A backlog is difficult to manage at 40 items, let alone 400.
- I always want to make sure my work is completable in a subset of a sprint while maintaining the context of what is trying to be achieved.
- I want time-effective meetings. Nothing gets people disengaged quicker than long planning meetings.
Interested and want some pointers on how to start? Try these:
- At each level of planning, create some baseline ranges the size a story needs to fit into to be ‘enough’. At a product backlog level, that is going to be high, maybe no maximum. To go to a release plan, a story cannot be any larger than 20. For a sprint planning session, no story will be over a 5.
- Timebox your planning sessions – for example at sprint planning we will spend up to 10 minutes discussing a story. If it is still confusing after that, is there a subset we can extract and leave the confusing part for further investigation?
- Review these constantly and adjust. Remember one size does not fit all.
Read more by Joel Tosi @ communalosmosis.com