The team is reviewing user stories during backlog refinement, and you notice that some of them are too cumbersome to work through. What do you do? Panic? Go for coffee? Nope! Gather a small team – usually, this consists of the product owner, ScrumMaster, and a senior developer or two – and formulate a plan. It’s time to split stories.
Why just this group? The product owner is in charge of the product backlog, so they must be present in all story splitting processes. They can make key decisions when splitting user stories by priority and they can select where in the backlog the lower-priority stories go. The ScrumMaster, who is the embedded Scrum coach on the team, can help move the process along. Having one or two senior developers is helpful as they provide the technical perspective. The developers can assist in figuring out the most implementation-friendly breakpoints between stories and can help ensure each split story represents a vertical slice through all the layers of the application, avoiding those that do not deliver value to the end-user.
You’ve split up your user stories. Now what?
It’s easy to fall into the trap of the resulting stories not being quite right. Perhaps the stories have started to slip back into a waterfall approach, where one story focuses on coding while another on testing. Do not go gentle into that good night… use the INVEST framework to ensure quality story splits to stay on the agile track.
Independent
In an ideal world, user stories are not tied to one another; they should be able to be implemented in any order. Having independent stories is helpful to the product owner so they can reorder the product backlog as necessary. For the development team, having independent stories means more effective development. There will be less stepping on one another if the team is able to divide and conquer more than one user story at a time. At times there may be some order dependency in your product backlog but try to keep it at a minimum.
Negotiable
A good user story provides a high-level overview without including every possible detail. By providing flexibility, the development team can work collaboratively with the product owner during the sprint. A list of five to ten acceptance criteria with few specifications for each story is a great way to keep stories negotiable. As each story nears the top of the product backlog and is discussed with the team, additional details are often added. Often, they are not needed until development nears.
Valuable
Each user story must provide at least some value to the end-user. This is what prevents you from creating stories representing horizontal slices – the data layer, the business layer, the presentation layer, etc. Even though a story may not deliver enough functionality to warrant a new product release, incremental value is provided, and the functionality is useable.
Estimable
User stories need enough detail to allow the development team to assign a story point estimate. The information provided should give the team enough detail to compare it to other stories. If the story involves technology or techniques that are unfamiliar to the team, or if there is vagueness present, the team could assign an inflated estimate. It says, “We’re not sure about a lot of this.” If a better estimate is needed, the team may use a spike to do some technical research to better understand what’s involved.
Small
Stories lower down on the backlog can be larger, but those near the top need to be small enough to accomplish in a sprint. A good plan for splitting user stories is to split them to a size that allows three to four of them to fit into a sprint.
How do we measure small? A good rule of thumb for splitting user stories is that no one story should be larger than 25% to 33% of the team’s average velocity from the last three sprints. Or, if the team is new, split stories so they are no larger than three points.
Testable
The story needs to be clear enough so the team can figure out how the user story will be tested once implemented. If it is not clear, it may not deliver value. Acceptance tests are a great way to ensure the story is in fact testable; these should be written early in the sprint, as they serve as a “beta test” to the story.
Once the stories are split, the entire team will repoint the new stories during the next backlog refinement ceremony, using the Planning Poker process. The backlog refinement ceremony is when the entire development team gets smart about the new stories and one of the main outputs is accurate story points.
Adding it up
So do the new stories have to add up to the same number of points as the old story? No! It’s perfectly acceptable and expected that when splitting user stories, the resulting stories add up to fewer points than the initial story. But what if they add up to more than the initial story? Take a step back and ask, “What’s happening here?” Was the development team too optimistic when they assigned the original estimate? Is it possible they didn’t really understand the story until the splitting process happened and more detail was added? Or are they being overly pessimistic with the split stories?
A good guide: the split stories should add up to approximately plus or minus 50% of the original story, which is the margin of error of the story point estimating technique.
One last note: stories that are too small can introduce excess overhead. If you have 20 stories in a two-week sprint, with 10 working days, that means the development team needs to design, code, test, fix bugs, and have the product owner review two stories every day, including on sprint planning day! Again, staying between 25% and 33% of the team’s average velocity from the last three sprints is best. Usually, you will end up with three to four stories in each sprint.
“Agile is simple – it just isn’t easy. “
Ron Jeffries, Founder of XP Programming.
