Agile Business Change Blog Thoughts on Agile Strategic Business Change and Agile Delivery

Tweet

Mail

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 for 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 point of being ignored. This leads inexorably to Stories which are no more than Tasks, and a resultant poor-quality product backlog. A set of tasks which are not valid increments (the subject of a previous blog) completely miss 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, and they should be 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 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.