Have Your Slice and Eat It: Boost Quality with Vertical Story Slicing

Using software testing as the only approach to building a quality product is possible, but it's a costly, time-consuming way to deliver quality. Instead, think about quality as an emergent property. Many factors affect product quality. One of these is how we slice our epics and stories.

I reckon even Goldilocks would have a hard time slicing stories. It is not easy to slice them so they come out 'just right'. Just-right stories are small, testable pieces of work that deliver customer value. Well-written stories will closely mimic the INVEST principles. INVEST stands for Independent, Nominal, Valuable, Estimatable, Small, and Testable.

But unfortunately, stories written this well are atypical. Instead, stories appear vague, obscure, large, dependent and hard to test.

One of the main antipatterns I see is stories that focus on the work at hand rather than the customer. Stories become "as a backend engineer, I will develop an api so that I can connect to the front end". Here, the story is sliced horizontally by architecture rather than by business value. Slicing a story in this way requires less cognitive load and avoids the need to predict what customer value might look like. It also means work can be allocated independently with less need for communication and collaboration.

But it's this lack of collaboration and alignment that manifests as poor quality.

Working independently can seem efficient, but it comes with risk and cost to quality. Without explicitly defining customer value through testable acceptance criteria, team members lean to testing output instead of the outcome. For example, "As a producer, I have an api that others may consume" results in testing that the API is exposed with the right fields and will most likely test for that. Customer value is implied as something to be discovered at integration rather than made explicit from day one.

Without realising it, team members make implicit assumptions about the nature of customer value. There's no real need to clarify if their assumpion is correct. The end result is it's only during user-focused software testing that teams discover if these assumptions are correct. I remember working with a software engineer who spent two weeks carefully crafting a backend API, only to discover right before deployment that the feature had been deprecated.

Slicing stories vertically requires that conversation on customer value to be up front with the whole team. Value becomes formalised. Example Mapping makes it even more explicit.

Another antipattern I see is the presence of unknown dependencies. This one is a killer when you work in large, complex, multi-system environments. Without understanding dependencies up front, teams lean on integration test environments to debug their assumptions. Given that most integration test environments are overutilised, this extra load puts immense strain on the overall system. Bottlenecks either emerge or become larger. Testing extends into large brittle phases, and behaviour shifts to firefighting mode. Estimation and predictability go out the window; uncertainty and micromanagement creep in, with senior management scratching their heads and muttering, “How the hell did we get here?”

Given the obvious benefits, why don’t we slice stories vertically? My theory is that doing so is difficult. It requires making the unknown explicit when lot of uncertainty still exists, and that’s not easy. Slicing stories well is a skill; It hard to know exactly where to slice the story and what the customer value should be measured in. It sometimes requires us to make a best guess and, faced with new information, to commit to rewriting the stories. Not every organisation affords this trust.

It also requires increased collaboration and communication.

When we commit to small slices of customer value, all team members work on the same story. That means the back-end, front-end, designers, and quality engineers work in parallel which requires preplanning and knowledge.

Schemas must be defined in YAML files. As new information emerges, change is required and realignment becomes necessary. This requires constant communication through pairing across role types and frequent shoulder checks. It might require working in the same repo, making the work more transparent.

It's a different way of working, one that may require behavioural change. One that not every team or company is comfortable with. But if they do, the benefits are priceless.

As quality coaches, how can we help teams slice stories this way? My approach is to make story splitting as easy and as frictionless as possible. I’m experimenting with AI to help create user stories. I'm exploring ways to offer feedback in safe environments through retrospectives.

I’ve developed a training tool called the Epic Slicer to help teams learn how to slice stories by customer value. The Epic Slicer has predefined epics for slicing. Based loosely on the Shu, Ha, Ri concept, it invites users to explore what well-written stories look like. It then encourages users to practice slicing the epic into stories with well-written acceptance criteria. The tool offers feedback on these stories based on the INVEST principles.

The tool is free to use and available to anyone who wants to coach teams on vertical story slicing.

Let me know how you go!

Recommended Reading on Slicing

Estimation Sucks. Let’s fix it.

The problem with estimation is that everyone is trying to get better at being right. Let’s instead get better at being wrong.

Tom Ridge | Showing my workTom Ridge