Story Splitting Tips: Notes from the trenches
While there are many techniques to split stories, here is our collection of top 10 story splitting tips based on Bill Wake’s INVEST model. These tips are collated both from knowledge gained from industry leaders and our own experience working across various organizations and teams.
If you need more information on INVEST criteria, you can find it here.
Tip 1: Size Matters, at least in the world of user stories.
The “S” in INVEST was small in Bill Wake’s original version of INVEST. Since then, “S” has been reinterpreted as Sized Appropriately. When a story is first added into the backlog, it is going to be large. Come implementation time, it is time to break down the stories — because smaller stories mean
- Faster time to value
- Lesser uncertainty allowing for increased control
- Smoother flow. Large User Stories can clog up the Sprint
- Opportunities for users to provide frequent and regular feedback
- Product Owner can prioritise across variations and complexities and maximize value
What is the right size? Agile Coaches use a number of thumb rules — stories are sized less than 1/3 of the velocity of sprint, and/or stories take between 2 to 3 days of Development and Test effort and/or stories should never be longer than half the Sprint. However, the right size for your team is usually the largest size that the team is consistently known to deliver successfully within the Sprint.
Tip 2: It is important to remember that not all stories can meet all the INVEST criteria. We aim to make them meet as much of the INVEST criteria as possible. Sometimes it is a trade-off and we choose which of the characteristic is more important for the story in our context.
For example, Small and Independent are the opposite sides of the coin. The chances are that the smaller you break down the stories, the more dependent they are on each other. We might choose to keep a story larger than our desired team ground rule size but still shorter than Sprint length — so that the story is independent and can be worked on and delivered independently.
Similarly, the smaller you go, the negotiability of the story reduces. The story is meant to be about who, what and why and remains negotiable by avoiding the how/implementation. But as you split stories, the “how” seeps in. If your stories are very implementation specific, then it might be time to reconsider if you are splitting them too small.
Tip 3: Stories need to be valuable. How do you make stories of business value? Epics or Releases can be of business value/produce business outcome. Sprint-sized stories, because of their size, may not be of business value by themselves though contribute to business outcome. The stories should at least attempt to satisfy user need and be of user value. Sometimes it is even hard to breakdown into sprint-sized stories that would be of user value. If you cannot break it down to satisfy a user-need/sub-need, then create one that can provide learning. Learning can be technical feasibility, feedback from user on building the right thing or risk mitigation. Only if you are unable to break it down to provide user value, then you create stories that are building blocks.
Tip 4: If a story is inestimable because of the uncertainty associated with it, one way to solve the problem is by splitting the story to a spike and the story for actual development. Once the spike has been performed, there should be more information to estimate the actual development story.
Tip 5: Team Structure - whether component or feature teams etc. - will determine how stories are written and split so they can be delivered with minimal dependencies across teams. In this context, what is value, how do you still keep stories traceable to user need, how can the story be delivered by the team without cross-team dependencies etc., will impact the approach to story writing and splitting to creating valuable user stories.
Tip 6: Try to keep split stories similar sized for better predictability. Have an idea of the thumb rule for size as relevant to your team and try to keep all stories in a similar size range.
Tip 7: Choose the split that lets you deprioritize stories. Split the Must haves from the Should & Could haves allowing you to “Maximizing Value delivered” while simultaneously “Maximizing the work not done”. The Story Map Technique is a good technique to identify and split out the skeleton slow and alternate paths.
Tip 8: Stories should go through the technology stack to deliver user value. Stories split along technical boundaries are component stories and don’t deliver business value and neither are they independent. Hence the need for stories to be thin vertical slices or tracer bullet, as Mike Cohn calls it, that go through the technology stack providing a piece of functionality.
Tip 9: Stories & Acceptance Criteria need to be objective not subjective, specific not broad, avoid vague words and fuzziness to be Testable. For example a story that says the app should run on top 3 home devices in the Asia Pacific market would be more testable that one that says that the app should run on all home devices.
Tip 10: The clichéd last but not the least tip, If you don’t start with a parent — epic or story that meets the INVEST criteria then the child stories will most likely not meet the INVEST Criteria. Restructure and validate that the parent story/epic meets the criteria before you start splitting the child stories.
References:
Bill Wake’s original article: INVEST in Good Stories and SMART Tasks
The bonus INVEST ebook by Bill Wake: INVEST in Good Stories - The Series
