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

This entry was posted in Agile Management. Bookmark the permalink.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>