One of the key techniques in the mechanics of agile software development is the splitting of large, monolithic masses of work (epics) into small, independently deliverable chunks of product (stories).
When using an outside-in or user-centric approach to developing software, the requirements are easily expressed in the format of a user story—As a [role] I need to [do something] so that I can [realize value].
This works well because you’re framing the work in terms of how someone benefits from what you create, not an inside-out view of what you need to build. You deliver capabilities—not artifacts and plumbing.
The challenge comes when the capability is too large to be entirely delivered in a single iteration. Mike Cohn has published examples from his experience. Both provide good insight into how splitting can work well.
Splitting stories is something that feels awkward at first, but you get better at doing it as you do it. The key principle is to get incremental value from each sub-story and minimize the risk of wasted effort.
Richard Lawrence has published an excellent mind-map providing guidance to help you choose how to split each story. Discover to Deliver, by Ellen Gottesdiener and Mary Gorman, provides contextualized examples and techniques as a fictional team works through the product creation process.
Armed with these techniques, any team can split stories. With a guiding principle of delivering value (ideally, to the customer; minimally, to the team) with each story, there will be ways to split things that make sense, and these examples will help you find them.
There is still an open debate between breadth-first and depth-first development—slicing horizontally or vertically. Good software is usually architected with horizontal abstraction layers, making it more adaptable to change. The simplest example would be the user interface, the logic layer, and a back end for persistence.
But users don’t care about how the product is built. Users care about achieving their goals, each of which would reflect a vertical slice through the layers. Should the team split stories to build cohesive layers first or structurally questionable slices through all of the conceptual layers?
Cohn addresses this question in the comments below his examples with a great counter-argument to the efficiency of designing a cohesive API vs. an emergent design that may drive the need to refactor later.
When scope is cut—delivery time and resources are regularly constrained, so this happens frequently—all of the effort put into the now-not-needed horizontal infrastructure is wasted or at least the value is not realized.
Alternately, investments in the parts that users don’t see are made in a vacuum and run the risk of being discarded or needing to be rebuilt once greater clarity about user goals is achieved.
Cohn demonstrates that teams need to strike a balance between predicting everything (horizontal efficiencies) and being tactically reactive and refactoring (vertical efficiencies). Neither extreme is ideal. The answer lies in a balance between the two extremes.
