Not every user story cleaves as easily as wood into more manageable parts. Sometimes, you divide the story only to find that you still are not satisfied with the results. Mike Cohn believes there are some common causes at the root of these issues. In a post at Mountain Goat Software, he identifies five story-splitting mistakes you should avoid for an easier life of storytelling:
- Treating it as just the job of the product owner
- Splitting stories along technical boundaries
- Specifying the solution as part of the story
- Using a spike on every story
- Thinking all business rules need to be enforced from the start
A Messy Break Up
One of the main issues with trying to shunt story-splitting duty off onto product owners is that they typically have a non-technical background. That means they may end up splitting stories in a way that ostensibly makes sense but is actually completely impractical from a development perspective. To avoid this, have one or two rotating members of the team assist the product owner in dividing stories.
Cohn also cautions against splitting stories according to technical boundaries. He finds that the best stories are the ones that go full-stack with the technology and are conceived from the view of the users and/or stakeholders. An alternative to splitting along technical boundaries is to split along story “paths”—the “paths through the code the team will write.” Look for the path of least resistance that minimizes risks.
The third mistake, specifying the solution as part of the story, can be symptomatic of a story that is actually too small. If a piece of work is so small that explaining how to complete it can be capably inserted into the story itself, you have delved too deep into splitting. Back up—particularly because going too specific with the details of one small section can accidentally handicap other interdependent sections of the project.
In the pursuit of feeling confident in their knowledge, teams might make the fourth mistake of using too many spikes in their stories. This can be an inefficient use of time. Be confident that you can get by without spikes in most cases, and reserve the use of them for times when uncertainty is truly high and concerning.
Finally, about trying to enforce existing business rules too early, Cohn says this:
If this rule makes the story take so long that it will not be feasible to implement the story within a single iteration, the rule should be relaxed (or removed) in the initial iteration and then added back in a subsequent iteration. And, no, the team shouldn’t release a product that violates business rules (temporarily).
The mistake I’ll see teams make is thinking that all such business rules need to [be]implemented right from the start. This often leads a team and product owner to instead use a less desirable way of splitting the story.
You can view the original article here: https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes-and-how-to-stop-making-them