Producing customer-centric backlog items with the following splitting techniques

Producing customer-centric backlog items with the following splitting techniques

Are your backlog items too large? Here are some techniques how to split them.

Vincent Van Gogh once said that “Great things are done by a series of small things brought together” and he couldn’t be more accurate as this can easily be applied to the art of splitting backlog items. Items should follow the INVEST Model – independent, negotiable, valuable, estimable, small and testable. Let’s focus on the “small” and “valuable” aspects of the model here. Sometimes items tend to be bigger than expected. In order to mitigate this and ensure that an item can be accomplished within a sprint you can use splitting techniques to split up items and look at the functionalities from different angles. Important is that you apply a vertical slice rather than a horizontal slice. The “valuable” aspect shall be intertwined with the “small” aspect, which means that when splitting items small enough they should be customer-centric.

There are a number of strategies to be used to split items. One goal is to have customer-centric backlog items that you can work with. The art herein is to find out which one is right for you. Use the following steps to assist you in this process:

  1. Choose the split that lets you deprioritize or throw away a story.
  2. Choose the split that gets you more equally sized small stories.
  3. Choose the split that does not create new dependencies.

Splitting techniques

A method to describe items is to write user stories. The emphasis here is placed on the end user and should therefore be the focal point of your understanding when writing user stories. In the following I will introduce you to some techniques on how to split an item based on the user story format.


What this is: Does the story include multiple operations? Can you split the story based on different operations (create, read, update, delete)?

Example: As a user, I can set up a user account and maintain it.

…I can create my user account to buy goods.
…I can modify my user account to change settings and personal data.
…I can delete my user account.

Workflow Steps

What this is: Does your story involve a workflow of some kind? Usually you can split the story into individual steps. Ask yourself: Can you split the story so you do the beginning and end of the workflow first and enhance it with stories from middle of the workflow OR can you take a thin slice through the workflow first and enhance it with more stories later?

Example: As a user I can log into my user account and change my password.

…I can log into my user account.
…I can change my password.

Business Rule Variations

What this is: Does the story have a variety of business rules? Business rules usually indicate constraints / restrictions applying for a feature. Consider if you can split the story to do a subset of rules first and enhance with additional rules later?

Example: As a user I can search for flights with flexible dates.

…as “n days between x and y”.
…as “a weekend in December”.
…as “± n days of x and y“.

Simple / Complex

What this is: Can you identify a simple core to the story which provides the most value? Think about if you can identify a simple core to the story first before you approach the more complex parts.

Example: As a user I can book a vacation with flight and hotel.

…I can filter by reviews.
…I can choose if I want breakfast included or not.
…I can filter by nearby parking or if an airport shuttle is included.

Defer Performance

What this is: Can you split the story to deliver the necessary functionality first and then subsequently add additional stories focused on improving aspects such as performance, scalability and usability (non-functional requirements)?

Example: As a user I can search for flights between two destinations.

…I receive a “searching” animation to bypass loading time.
…I can load the site under 5 seconds and almost instantly receive my results.

Major Effort

What this is: When you apply the obvious split, is whichever story you do first the most difficult? Could you group the later stories and defer the decision about which story comes first?

Example: As a user I can pay for my products with all credit card types (Visa, MC, DC, Amex).

…I can pay with one credit card type (Amex, MC, Visa, DC).
…I can pay with all credit card types, given one card type already done.

Interface Variations

What this is: Does the story have a complex interface? If yes, is there a simple version you could do first and everything else incrementally after?

Example: As a user I would like to access the menu of a restaurant on a website.

…I can view the menu as a PDF document.
…I can view the entire menu on a web page.

Variations in Data

What this is: Does the story do the same thing to different types of data? Create a story for each option.

Example: As a user in an online shop I want to view the site in my native language.

…in English.
…In German.
…In French.

Break out a Spike

What this is: Not sure about how to split the story? Can you find something which is already clear and can be implemented? Write this story first and build it. If the story is not clear at all, it may be time for some research and investigation.

Example: As a user I would like to be able to save my products into a wishlist.

…Investigate how to implement a wishlist.
…Implement the wishlist.

Find a nice visualization of the different techniques right here.

LeSS Friendly Splitting Techniques

In LeSS there are two primary strategies that can be applied in the backlog when splitting large backlog items. You remove the ancestor when applying a method called cell-based splitting or you keep the ancestor by using the tree-based splitting technique. Let’s look at the two techniques and identify advantages and disadvantages.

This technique is used in a LeSS (Large-Scale Scrum) context by teams to discover new items and presents a source of inspiration. This is where the ancestor disappears and the backlog would in that regard not directly reflect the ancestor-relationships. At the end you are presented with finer-grained leaves which demonstrate a functionality. Ancestor-relationships can be kept with tags or are anchored to a common ancestor each.

The real advantage as Craig Larman points out in his book “Practices for Scaling Lean & Agile Development” lies in its simplicity. It is about embracing the ideology of not caring about what may be potentially useful. A second advantage lies in the absolute independence of an item compared to others as the items are disconnected from an ancestor. He points out that “a sub-item does not inherit the priority of its ancestor. This is a key mindset change for product management”.


Tree-based splitting (tree-like splitting)

Tree-based splitting takes an opposite approach. You keep the ancestor Item. A perceived advantage lies in the big picture context. Furthermore, it typically leads to creating new sub-items and items are only done, when all sub-items are done. The Product Owner here will maintain ancestor links in the Product Backlog. As Larman and Vodde outline in the book “Large Scale Scrum: More with LeSS” you can add a new column to your backlog to store the ancestor information for instance. A clear disadvantage however is that there ultimately is more information to process and manage dependent on how deep you intend to split down.


Splitting perspectives in LeSS

Splitting perspectives are techniques that can be used to split and structure backlog items when using a cell-based or tree-based splitting introduced by Craig Larman. They are similar to the techniques of splitting user stories which were explained earlier in this article.

In Craig Larmans “Practices for Scaling Lean & Agile Development” he is presenting a large number of perspectives on how to split items. Among those are splitting by use case, configuration, data format, role or persona and scenario. Ask yourself What perspectives are there in this item? and what technique will effectively help me to discover the core?

Let’s more closely look at two of those techniques:

Split by use case

What this is: A use case delivers independent customer-centric value. Based on use cases you can set priorities for the delivery of value to the end user.

Example: As a user I would like to have a new product detail page so that I can more conveniently read about the USPs of the product and get feedback on how other people like it.

…I can read about the benefits of the product.
…I can read customer reviews to evaluate the product.

Split by scenario

What this is: In order for customers to achieve their goal they make go through different scenarios. They may enter an invalid email address when entering their purchase data, may search for a product which is not in stock and so on. In order to better understand the user journey you can split up a story into scenarios.

Example: As a user I would like to sign into my user account so I can look at my profile and modify it.

…I can successfully log into my account.
…I failed to login because I typed in wrong credentials three times (lock account).
…My account is locked.

Go practice

There are many more splitting techniques to be used when attempting to split stories to make them more digestible and fitting for a sprint. Ultimately the team has to decide which techniques work the best for them. It is also a reflection of the nature of the product you are working with and the industry you are operating in. Some techniques may be less suitable, some will surely work better and relieve some headache for the team in finding valuable and customer-oriented items to deliver to the end-user.

Happy Splitting!