In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set here. The next seven blog posts are expanded versions from “Seven Strategies for Splitting Stories”. You can find the original post here.
Story splitting is one of the critical skills in Agile software development. We want stories to be small, as small as possible while still deriving some value to the user.
Story breakdown is both an art and a science that requires learnable skills. I worked on several projects where I thought that our work was so large that it would be very difficult to extract out small stories, only to be proven wrong. I’ve been able to extract small stories from every domain that I’ve worked in. It is not that difficult if we understand how to break out our work to provide the highest value with the fastest delivery time.
We like short stories because stories that are short tend to be more cohesive and uncoupled from other stories. This means that the code that is generated from short stories tends to be more focused and well encapsulated with clearly defined responsibilities.
Shorter stories are also easier to test and validate. The biggest benefit of short stories is that we can implement them quickly so that we can get feedback on them quickly. Agile is all about feedback.
How small should a story be? As small as possible and ideally, I would like my stories to be completed within about four hours. Obviously, there are many kinds of stories that require more time than that, but if I can split out a piece of work into a four-hour chunk then that’s ideal for me.
My reward for breaking stories down into small, heterogeneous chunks is that I no longer have to use story points. I’ve seen story points in Scrum estimation be misused because when we try to use it to measure productivity we almost always fail. Story points weren’t intended to be a productivity measurement. Story points were intended as a capacity measurement.
But if we are able to break out stories or tasks into heterogeneous chunks of work then there’s no need to assign story points to them. We can simply count stories instead of having to estimate the complexity of each story. Then we just look at how many stories we’ve completed during the last iteration and very likely this is the number of stories that will be able to complete in the current iteration. Therefore, there is no need for estimation based on story points.
The first strategy that I want to share with you for splitting stories is one that I use the most. It’s simply about disaggregating stories that are embedded in existing stories. Oftentimes, a story can be broken out into multiple stories because the story is made up of several sub-stories.
If the story is a compound story, then we simply break it down into its components and have each one of its components act as a separate story. This yields smaller stories that are more straightforward to work with.
Breaking down compound stories into their components is the number one technique that I use for breaking down stories. But there are several other techniques that are useful for breaking down stories, which we will cover in the next six upcoming blog posts, so stay tuned.
Previous Post: « Use Acceptance Criteria for Stories
Next Post: Break Complex Stories Down into Knowns and Unknowns »