Updated: Jan 28, 2020
Having worked with many clients 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, 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.
Why split stories vertically?
Firstly, why not? 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 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.
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:
Vertically sliced stories facilitate deep collaboration and generate a 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
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 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 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 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.
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!