How to Slice Stories for Maximum Value

Having worked with many many teams across multiple industries, one of the big things I see teams struggle with is how best to slice stories. Effectively sliced stories improve story flow during development, increase value delivered, reduce rework, remove the assumed scope and increase predictability. Many of these benefits come from the team collaboratively working together on customer-focused stories which deliver tangible business value.

Getting this right is tough, with teams often splitting stories by layers of the system, such as into UI and APIs. With a little bit of knowledge of effective story splitting patterns and techniques, resolving this challenge is surprisingly quick and easy.

First, let's get clear on what it's a bad idea not to slice.

What happens if we don't slice?

Put simply, you end up with large User Stories which takes weeks to deliver. This increases the risk of a deployment, increases overhead for customers trying to use the feature and delays the business benefit. 

If a team recognises the need to break a story down due to its size, sometimes they'll split it horizontally. Splitting stories horizontally is the alternative whereby stories a split by application layers (client app, server app, DB etc). This raises a number of challenges:

• Stories do not deliver incremental business value.
• It’s a traditional concept that encourages silo thinking, reduces collaboration and establishes sub-optimisation (i.e. I’ll just get my bit done as quickly as possible, everyone one else be damned!).
• Hides defects/design faults until they are implemented in their entirety
• Duplication of QA efforts.
• Juggling multiple dependant stories creates a prioritisation nightmare
• Related to all of these points, it may feel like we’re going quicker, but really, we’re just creating bottlenecks that we’ll need to face down the track.

What happens if we do slice?

Splitting stories vertically, on the other hand, involves breaking stories into smaller, more manageable functional components which deliver business value (see also INVEST acronym for a useful indicator of quality stories).

This presents the following benefits:

1. Vertically sliced stories facilitate deep collaboration and generate a shared understanding of the objective of each story, rather than specifically a predefined solution/implementation.
2. Every story delivers business value that can be tested with users (or even released to market), providing rapid feedback and the opportunity to pivot the feature set where required.
3. Smaller stories help us move faster, increase flow and reduce batch size. Small and similar-sized stories allow us to forecast delivery dates (when required), rather than estimate each story. Stories are easily tested within the iteration they are developed as they are smaller and less complex.
4. Prioritisation is simplified and transparent. Projects run leaner as often, by breaking features down, we realise what is important and can discard everything else.

It’s all-inclusive: we have the same goal of getting the whole feature completed (rather than just my bit).

Patterns for Splitting Stories Vertically

There are some common patterns to follow when slicing features:

The Hamburger technique

Some stories are inherently hard to break down, particularly when we’re playing the first few stories to create a product that lay the foundation for the rest of the platform to be built. This is where I have found the Hamburger Story Splitting comes into its own!

Step 1: Identify tasks to deliver a story

Break the story into high-level implementation tasks or components. This forms the basis for our options at each level.

Step 2: Identify solution options for tasks/components

Now we know have a high-level view of what needs to be done, we can come up with solutions for each layer. Initially, do this individually, then add them to the burger. Remove duplicates as you go.

Step 3: Trim the burger

Remove the options we flat out don’t want to do.

Step 4: Take your first bite

Take the first bite of the burger creating the minimum slice of functionality necessary to create value. Remember, it does not need to be shippable on the first few slices, just be sure that it creates real value.

Step 5: Rinse & repeat

The initial slice will give us a very basic feature which may or may not be enough to ship. We, therefore, repeat step 4 to iterate our way towards a shippable feature!

Bonus: Hello World Method

Slicing our first story on a product can be really difficult. Our first story will lay the groundwork for everything to follow. It’ll implement our Continuous Integration setup, Deployment Pipelines, core services, and the list goes on. Either that or we play the dreaded sprint 0 cards, without creating anything which even remotely reflects the business value in the first sprint.

Well, what if our first story was simply a “Hello World” app, implementing the core of our infrastructure and services, continuously integrated, deployed and tested? This is my go-to technique when starting out teams on continuous deployment and microservice journey. The objective here is to create a walking skeleton that provides the perfect foundation for us to build our first real story. It should take no longer than a few days to create.

This walking skeleton may entail a couple of microservices and a basic HTML UI. It’s unlikely to have any storage, anything more than one path (Hello World) and certainly will not represent anything which reflects a launchable feature. If it does, then you’ve probably done too much.

Make these patterns stick

The hardest part really is establishing this as a habit for your team. The best way to tackle this is by having them try the techniques out in an exercise format removed from the work they do day to day, such as Cockburn’s Elephant Carpaccio exercise.

We have a range of short and focused training sessions/workshops for these techniques. If you’d like to hear more, please contact us!

Bringing it all together

Effective story splitting techniques will help you move faster, reduce scope, reduce batch size and keep focused on the customer. First, get familiar with these techniques, then run some exercises with the team to obtain a deeper understanding of the patterns. Finally, print this article out and keep it handy for anytime your team goes into story splitting mode.

Try these techniques out and let me know how you get on!