Thursday, March 3, 2022

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:

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


  1. I agree on building integrated testable vertical products soon.

    But I think it is a mistake to imply that Cascade is the same as Top Down Bottom Up.

    There is no space to Top Down Bottom Up, even while building this end to end vertical partial solutions.

    Top Down Bottom Up is just another way to think about "Divide and Conquer". The "tree" produced by the "Down" phase is just a dependency hierarchy of problems to be solved, and there is no option, but to solve them bottom up.

    You have your "minimal testable product", still it has to be solved methodically, first by it's own sub problems and then integrating.

  2. Truth. That "divide and conquer" is even backward. The point of Divide and Conquer is that the divided entity is the one defeated. You split the enemy's forces so that you can take them out in groups.

    In the software world, we divide ourselves. That's like "separate and be defeated" not "divide and conquer". It's like in the slasher movie where the lights are out and there is a killer in the house, so they all split up and take different floors to find him.