Skip to main content

The search for small

22 May 2012

| Author: James Yoxall


The search for small

It is generally accepted that stories should be small. Some teams even demand that "no story should be bigger than a few days". Unfortunately, focusing on smallness can lead to confusion and reduce the benefits of Agile.

This is the third blog in a series which aims to provide a clear and practical set of criteria for good stories.

Pooh remembered that he had forgotten to ask who Small was, and whether he was the sort of friend-and-relation who settled on one’s nose, or the sort who got trodden on by mistake.

The House at Pooh Corner, AA Milne

It is clearly true that small stories are essential in order to manage work in sprints. Here is the problem though: if a story is as small as it can be and still meet all the other criteria of a good story, but it is still not small enough to schedule within a sprint, how can you make it smaller?

The only option is to relax the other criteria. Unfortunately, there is a tendency when focusing on the small that other criteria get relaxed to the point of being ignored. This leads inexorably to stories which are no more than tasks, and a resultant poor-quality product backlog. To create a set of tasks which are not valid increments (the subject of a previous blog) completely misses the point of Agile, and the product backlog ends up having no more value than a traditional Gantt chart.

At IndigoBlue, we use a different approach: we focus on getting stories as small as they can be, but no smaller. The process of story refinement is therefore correctly the art of finding ways to deliver something smaller which is still complete and still provides value. When this is finished, there will still be stories that are too large – maybe even stories that will take multiple sprints to complete. This is often true at the start of a project, where the first journey is from nothing to the smallest complete, end-to-end system.

When it becomes necessary, we move deliberately into a different mode of refinement, where stories are broken into smaller parts purely to support scheduling in sprints. We call these smaller parts 'sub-stories' to make it clear they are not stories.

The difference between stories and sub-stories is well-defined. Stories are true increments, meeting the joint criteria that they should be:

  • testable using end-user functionality
  • complete systems that provide real additional value if deployed

For sub-stories, we relax the criteria for value but not for testability, so a sub-story must still be testable using end-user functionality. A typical example would be to take an end-to-end business process that is required (at a basic level) in its totality in order to be complete and valuable, and then to divide it into individual steps that are testable in their own right.

The difference between a story and sub-story may seem subtle and pedantic, but the importance is in the discussion as to whether something is one or the other: the answer depends on whether the sub-story is valuable in its own right. This is exactly the right discussion to be having.

Subscribe to receive our email updates


Author profile image

James Yoxall

Joint founder of IndigoBlue, James is a recognised expert in the Agile community. His work on Dynamic Uncertainty Management and Incremental Strategy has revolutionised the approach to the implementation of Agile at scale.


How can we help your organisation?

+44 (0)20 7692 4832

How will we use the information about you?

When you complete this form and submit your details, you are trusting us with your personal data. Our Privacy Notice informs you of what personal data we collect, why we collect it, and of your rights in relation to your data. By pressing submit, you indicate that you have read and accepted the terms of our Privacy Notice and that you consent to our processing of your personal data as described in the Privacy Notice.