Mike Cohn is a guy I respect for his practical experience which he uses to leaven (*) the theory of agile methods. To that end, consider his approach to not being too slavish to the construct of stories the first time they are written, to wit: it's sometimes necessary to split a story.
But: mistakes can be made. To avoid the most commonly made mistakes, Cohn's advice:
" ..... story splitting should be viewed as a whole-team activity. That doesn’t mean the whole team has to be involved in every split. Rather it means that splitting isn’t delegated to one or two people on the team who do it for every story."
Story splitting boundaries should be functional rather than technical in order that there be user value in the split story. Cohn: "A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own."
Stay functional. Focus on the functional "what" and not the technical "how" in stating the story narrative. "Including the solution within a story tends to happen when stories are being split too small. Once a story gets to a certain small size, there isn’t much more to say about the story and implementation details start to creep in when they shouldn’t."
Don't overuse the spike. " ... the mistake some teams will make is becoming over-reliant on spikes. ...
Spikes are most useful when a story includes an excessive amount of uncertainty, and when the team and product owner agree that uncertainty should be reduced before implementing the story."
-----------Story splitting boundaries should be functional rather than technical in order that there be user value in the split story. Cohn: "A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own."
Stay functional. Focus on the functional "what" and not the technical "how" in stating the story narrative. "Including the solution within a story tends to happen when stories are being split too small. Once a story gets to a certain small size, there isn’t much more to say about the story and implementation details start to creep in when they shouldn’t."
Don't overuse the spike. " ... the mistake some teams will make is becoming over-reliant on spikes. ...
Spikes are most useful when a story includes an excessive amount of uncertainty, and when the team and product owner agree that uncertainty should be reduced before implementing the story."
(*) leaven:
an agency or influence that produces a gradual change.
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
