Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Jun 21, 2010 — Enterprise Agile Planning expert

Stories and Size – What is too large when?

Enterprise Agile Planning


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 @

The post Stories and Size – What is too large when? appeared first on VersionOne Blog.


More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us