Have you ever faced a challenging task and been at a loss where to begin? No doubt you've discovered breaking the problem down into small and manageable chunks gives you a place to start while rewarding you as you tick off each milestone.

I regularly see teams struggle with the same problem where their backlogs containing almost exclusively large stories resulting in complex and cumbersome execution, and frustrated team members! Well sliced stories you'll notice improved flow, increased value delivered, reduced rework, less assumed scope and increased predictability. As with everything, there is a right way and a wrong way!

Horizontal vs. Vertical Slicing

When it comes to large stories, there are 2 slicing principles which are commonly used to break them into more manageable sizes: Vertical and Horizontal slicing. Vertical slicing entails breaking stories into smaller, more manageable components which deliver business value (see also INVEST acronym for a useful indicator of quality stories). Horizontal slicing is the alternative to vertical slicing were 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 which 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.


This presents the following benefits:

  • Vertically sliced stories facilitate deep collaboration and generate shared understanding of the objective of each story, rather than specifically a predefined solution/implementation

  • Every story delivers business value which can be tested with users (or even released to market), providing rapid feedback and opportunity to pivot the feature set where required

  • 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

  • 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

In 2009, Richard Lawrence suggested a series of patterns to effectively slice stories. These patterns are simple, yet effective and therefore are my go to method to split stories. I’ve slightly modified this for your

Source: http://agileforall.com/patterns-for-splitting-user-stories/


Original Story

Split Story

Major Effort

As a customer, I want to pay for my flight with VISA, MasterCard,
Diners Club, or American Express

  • I want to pay with one credit card issuer

  • I want to pay with four credit card issuer

Happy vs unhappy path

As a customer, I want to send a message and be notified if there is a failure

  • I want to send message

  • I want to be notified when the recipient does not exist

  • I want to be notified when a generic error has occurred

Workflow Steps

As a content manager, I want to publish a news story to the corporate website

  • I want to publish a news story directly to the corporate website

  • I want to publish a news story with editor review

  • I want to publish a news story with legal review

Business Rule Variations

As a user, I want to search for flights with flexible dates

  • leaving date x and returning date  y

  • “n” days between leaving date x and returning date  y

  • a weekend in December

  • ± “n” days of x and y


As a user, I want to search for flights between two destinations

  • specifying a max number of stops

  • including nearby airports

  • using flexible dates

  • etc

Variations in Data

As a sales rep, I want to calculate state sales tax

  • in Alabama

  • In Colorado

  • In Kansas

  • etc

Data Entry Methods

As a user, I want to search for flights between two destinations

  • using simple date input

  • with a fancy calendar UI

Defer Performance

As a user, I want to search for flights between two destinations

  • (slow - just get it done, show a “searching” animation)

  • (in under 5 seconds)

Operations (e.g. CRUD)

As a user, I want to manage my account

  • I want to sign up for an account

  • I want to edit my account settings

  • I want to cancel my account

The Hamburger technique

Some stories are inherently hard to break down, particularly when we’re playing the first few stories to create a product which 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!

This technique comes from Gojko Adzic, where we break the story into solution options by task or tech layer. We then choose the minimum vertical path through each layer which will create business value. You can read more about his approach here: https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/

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 for a product can be really difficult. Our first story will lay the groundwork for everything to follow. It’ll implements our Continuous Integration setup, Deployment Pipelines, core services and the list goes on. Either that or we play the dreaded sprint 0 card, without creating anything which even remotely reflects 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 a continuous deployments and microservice  journey. The objective here is to create a walking skeleton which 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 with a sprinkling of AJAX to kick off a basic workflow. 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 you 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.

Skillfire offers 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!

Posted by Tim Newbold on December 11, 2016

blog comments powered by Disqus