The Three Keys to splitting User Stories effectively

Splitting Epics into Features is hard, splitting Features into User Stories is hard and splitting User Stories into smaller User Stories is hard. Of course it is easy to do any of those steps poorly, but we are talking about making effective splits. Effective in that the team is able to efficiently work together to continuously deliver something of value to the Product Owner. Effective in that product risk and project risk is being addressed, while maintaining a clear picture of the team’s progress. Effective in that the splits eventually result in User Stories that the team can tackle in a sprint, i.e. each User Story adheres to most of the INVEST principles.

In my mind there are three keys to unlocking the door to effective splitting of User Stories.

Key One: Understanding

Understanding is a critical key in getting teams to effectively split up User Stories. I am talking about refers to the whole team understanding the Big Picture, Business Benefit and Design.

Understanding the Big Picture
How does this User Story relate to the Feature and the Feature to the Epic? This is important because it allows the team to know which things they can defer, and knowing what can be deferred opens up plenty of options for splitting User Stories. There is more discussion of deferring things in ‘Key: Thinking Vertical’. To achieve understanding of the Big Picture it is essential that the team is involved in splitting the Epic into smaller Product Backlog Items, early in the Release Planning process ideally as it the Epic is being split into Features. If the team was not involved in splitting up the Epic from the beginning, the Product Owner should make sure that the team is aware of the big picture, probably by describing the relationship between the features to the Epic.

Understand the Business Benefit
The team should understand the business benefit that the Feature should deliver and how that contributes to the business benefit of the Epic. Understanding of the business benefit helps the team to make smart choices about how to split up the Feature. I have found that teams who do not understand the business benefit can end up making choices that unintentionally diminish those benefits. For example they may reduce the amount of error validation that is done, thinking that it is good way of keeping costs down. However, when the business benefit centres around an awesome user experience bringing customers back, this is a poor choice. In this case the reduced error handling may upset some users and hence the business benefit is also reduced. 

Understand the Design
The design should be understood by all members of the team, at least at a high level. This does not necessitate a lot of design to exist, the important point is that everyone in the team can talk in a common language about the design choices they are making and of course how that relates to splitting up the User Stories. For example testers should be able to hold meaningful conversations with developers about testing impacts based on the design and its relationship to split of User Stories. Sharing a common understanding of the design allows all members of the team to contribute ideas for splitting User Stories, which leads to item four.

Whole team understanding
The whole team should have a shared understanding of the big picture, business benefit and design. This shared understanding ensures that everyone can be involved in splitting up the User Stories and doing so in a way that represents their concerns. i.e. Testers can ensure that the User Story is Testable. Whole team understanding also speeds up estimation and builds the team commitment to delivering the User Story.

Key Two: Thinking vertically

Waterfall development generally builds up the product layer by layer, or component by component, this is what I call the horizontal approach. 

Image 1: horizontal development, the blue items are units of work / poor User Stories

The downsides to his approach when used for agile development is that it builds up debt, unbalances the work amongst the team, deprives the team of early feedback, hides issues and hence hinders our ability to be agile.

The key to addressing the issues of horizontal approach; is to think vertically, to think about delivering vertical slices. Building vertical slices means that each User Story builds a piece of each layer of the product, the User Story must adhere to the Definition of Done and deliver some business value or be a solid step* towards that value. 

Image 2: vertical development, the blue items are units of work / User Stories

Usually the code that is delivered with each vertical slice is very small compared to what developers would have experienced with the horizontal approach. Some people struggle with this, as they feel that they are going slower than they have in the past. Of course this is true so it is important that we explain to them all of the benefits that come with this approach, such as:

• Finding issues early as hence fixing them for less cost
• Not building the bits that we thought we needed at the start but later find out we don’t need
• The ability to get fast feedback from our Product Owner, peers and customers
• Realistic reporting of our progress towards done
• Delivering value with each User Story, as opposed to delivering untested code

An important concept to get across to teams that are new to the vertical approach is; they can be ruthless about things that get deferred within the release time frame. Take the example of building a new GUI customer search for call centre operators that allows for complex ‘SQL like’ queries to be create, executed and stored. There is no way we would release it to our customers with poor performance, no error handling, a clunky user experience, or half of the fields missing. Yet all of those things are great items to split out as separate User Stories, provided they will be delivered within the Release Time-frame.

*While I agree that User Stories should deliver some business value (The V from INVEST), I have found that by splitting up User Stories so that they are small enough to fit into a Sprint there are often times that the business value is not clear. At the Feature and/or Epic level it is clear what the business value is, and the User Story is clearly contributing towards that, but the User Story itself does not deliver much/if any value.

Key Three: Experience in splitting User Stories

This is a classic catch 22, a bit of experience in splitting User Stories seems to make it much easier to split the next User Story and opens up the mind to new ways of splitting User Stories. This is where an Agile Coach can really help, by working with the team to split their first couple of User Stories hence breaking out of the catch 22. Another option is to run workshops on splitting User Stories that include practical exercises. The workshops that I have run are always well received and provide teams with that vital kick start to their experiences.

For most developers that are new to agile, the vast majority of their experiences regarding splitting up work has been in splitting it horizontally. It is a hard habit to break out of thinking this way, again this is where an Agile Coach is very helpful; to show them new ways of thinking. This can be accomplished with a few hints, some probing questions and pressure for the team to stick to the Definition of Done, while delivering an increment of value.

Additionally to support the team in thinking about different splitting approaches I like to provide them with cheat sheets and short articles that describe different splitting approaches. Here are some of my favourite articles and cheat sheets: 

• Twenty ways to split Stories by Bill Wake - One page cheat sheet and blog with detailed explanation.
• Patterns for Splitting User Stories by Richard Lawrence - another cheat sheet and blog with detailed explanation. 
• How you'll probably learn to split features by J. B. Rainsberger - explains the transition in thinking about splitting that occurs for many people.
• Story weight reduction kit by James Grenning.

Causal Loop Diagrams

Thank you to Renae and Shane who helped me to find the answers to why our teams were struggling to split up Features into small User Stories. We found the answers by drawing a Causal Loop diagram together, you can find out more about Causal Loop diagrams in the book The Fifth Discipline by Peter M. Senge. If you are stuck on a complex problem, I highly recommend that you grab a couple of peers and get them to help you draw a Causal Loop Diagram about the problem.

Image 3: A snap shot of the Causal Loop Diagram that inspired this blog post.

Photo of keys by: mmarchin