Splitting Stories - A Resource Listicle

 I've noticed that for several years now, one of the most frequently asked questions in agile forums deals with the splitting of stories. 

We simply can't create a feature, epic, or improvement in a single gesture. If we are going to make progress, we have to start somewhere and build in small pieces. One way or another, whether we release after each piece or not, we have to make progress in bits and pieces. 

In the bad old waterfall days, the analysts and designers would come up with a system with functional decomposition. It would essentially describe a tree with upper-level modules calling lower-level modules all the way down to individual functions.

After the designers have done a top-down design, the developers would start building the system starting from the bottom-up. They would build the pieces and the higher-level pieces that use those pieces until they had components, sub-assemblies, subsystems, and eventually the entire product. 

This "top-down design, bottom-up implementation" had the advantage that pieces could be farmed out or assigned to a lot of individuals and as the parts started to integrate errors could be discovered. Sadly, full integration was one of the last activities possible in the system, and really large errors could be discovered late in the process. 

We tend to see that whole system - a master designer surrounded by minion "brick-makers" -- to be fraught with peril. There are just too many ways for the work to be wrong or late, and too little engagement of the intelligence of all the brick-building developers. These kinds of systems fail much more often than agile ways of working, according to Standish reports.

We find working in end-to-end slices to be superior as far as engaging the intelligence of our people, getting integration (and therefore bug detection) early and often, and in our ability to demonstrate a running, working system at all times. Rather than having 100% of the system N% complete and little to demonstrate, inspect, or use to acquire feedback, we always have N% of the system 100% done and demonstratable. 

This is a political and technical improvement in the way of working. Where it is practiced, teams are more successful in building products that satisfy the needs of the product community.

But how does one do that?

Here are some writeups that I like and recommend:

• Understand the process user stories are intended to support.
• What is a walking skeleton anyway?
• Josh Kerievsky's description of Evolutionary Design (the primitive whole, walking skeletons, etc)
• Learn why you need Whole Stories for Whole Teams
• Try Gojko Adzik's Hamburger Method
• Check out Neil Killick's capability slicing
• George Dinwiddie suggests splitting stories by testable requirements.
• Try Bargain Hunting
• See the nightmare of Scatter-Gather (and avoid it!!)
• Bill Wake's exploration of ways to grow systems
• A Dozen Ways to split stories 
• SPIDR - Mike Cohn's Spikes, Paths, Interfaces, Data, Rules method.
• Bill Wake's 20 collected ways to split stories
• Richard Lawrence's Story Splitting Flowchart is at the bottom of this page, with a lot of good expository text above.
• Dr. Balbe's fairly comprehensive guide, including INVEST and ZOM.
• For "what not to do" check out Cohn's 5 Mistakes article.
• A quick introduction to "tracer bullets" can't hurt.

Check out the 5 selected articles from Agile Alliance while you're at it.