Global IT Consultancy Xebia and Digital Specialist SwissQ Join Forces. Read full press release >

Backlog-Items and the «Art of Splitting / Slicing»


Lukas Rüdlinger, Senior Consultant

Probably every product owner, business analyst or requirements engineer has stumbled over the questions “Why do I need to split backlog items at all?” or “How do I split or slice backlog items in a meaningful way?”. It’s a recurring, much-discussed topic and an important skill for a product engineer. Although this activity is not rocket science, it should not be underestimated.

This blog sums up the most common challenges and explains the added value of splitting backlog items. Finally, simple and helpful hands-on tips are formulated for practical transfer. With these few tips and right thoughts in mind, you can quickly achieve good results. 

Splitting backlog items – regardless of whether they are epics, features or story items – sounds simple at first, but it does have its pitfalls. It is not uncommon to make bad experiences with slicing backlog items during a project. As a result, the next time it is simply done without. However, putting too large backlog items into development can have serious drawbacks or problems. Typical symptoms of too large or badly sliced backlog items are:

  • Long waiting time for a first version of the usable product or product increments
  • Development of individual backlog items takes forever or a very long time
  • Increased risk of individual backlog items
  • Implementation of backlog items that do not provide any user added value themselves
  • Individual backlog items can only be implemented in combination with other BL items (dependencies)
  • The difference in size / effort of the items in the backlog is considerable
  • Deployment of individual backlog items is difficult or not possible
  • It is difficult to define acceptance criteria and acceptance tests for individual backlog items

In practice, in many cases the root cause is misinterpreted or not investigated at all. The fact that a better splitting of backlog items reduces many problems is rarely recognized. It is not necessary to make a science out of it. You just have to keep a few principles in mind and ask yourself the right questions next time. 

What is the main benefit of small-sliced backlog items? And does this justify the effort required for this?

This fundamental question can be answered with countless arguments. However, the real essence lies in the principles and paradigms of agile product development – short feedback cycles and iterative development of the product. Based by this, the answer can be reduced to two crucial arguments. A continuous solution development in small steps….

  • Lowers the impact of assumptions and uncertainty. Faster implementation allows feedback to be obtained sooner, which in turn minimizes risk.
  • Reduces time-to-market. Getting to market earlier with a product is becoming more and more critical and has a significant impact on investment decisions.

Once you are convinced of the necessity and added value of splitting backlog items, the question inevitably arises as to which methodology or procedure should be used to slice items. There are several principles and techniques that provide guidance in this regard. The most common theories proclaim splitting according to the following eight rules or techniques:

Collection of the eight fundamental rules and techniques for cutting backlog items
Overview of typical splitting techniques. For more details, see “How to split a User Story” from humanizing work

hese theoretical methods help to establish a certain standardization in a team, but take practice and experience. Furthermore, there is no “one right” technique. Depending on the context and framework of a project, different techniques may or may not be applicable. Therefore, a combination of techniques is often necessary and useful. Other helpful and complementary tools are story maps, customer journeys, and service blueprints.

INVEST in quality first, then in splitting / slicing

It is intuitive and tempting to first break down (or split) a topic into small pieces and then enrich (refine) the items with details and specifications. Although this allows you to “finish” the first (smaller) backlog items more quickly, it becomes much more difficult to keep track of the overall picture and the sliced items. This approach is therefore a deceptive simplification and only postpones any inconsistencies or contradictions. Correctly, a topic should first be captured in its entirety and meet certain criteria before it is selected and sliced for implementation. A helpful and proven guidance for this is the acronym INVEST.

Visualization and description of the INVEST acronym as quality characteristics of backlog items
Explanation of the INVEST acronym, source: SwissQ, adapted from Bill Wake “INVEST in Good Stories

The aspects of the INVEST acronym represent so to speak quality criteria for backlog items. If these are taken into account and fulfilled as far as possible, a good precondition can be created for slicing backlog items. The underlying goal is always to enable the solution development in as small and continuous steps as possible.

To get started splitting backlog items, here are a few helpful tips and tricks in the form of simple questions to keep in mind:

  • Is the backlog item already well defined and does it meet the INVEST rule? 
    A backlog item should first be properly defined before it is split – and not vice versa
  • Does the backlog item have to be split at all? 
    Helpful rule of thumb: an item should not be bigger than 1/6 to 1/10 of the sprint capacity (Scrum) / throughput (Kanban)!
  • Can the use-case / content / scope of the item be simplified? 
    Try to apply the Minimal-Viable-Feature principle. Remove everything that is not really absolutely required
  • Can variation be removed at the beginning of a new feature? 
    It is often most economical and least risky to realize the full added value of a feature in steps one after the other. 
  • Which use-case provides the most added value or is most insightful?
    It usually makes the most sense to start with the greatest added value or the greatest learning potential during implementation
Illustration of a feature and its splitting / slicing in end-to-end variation for implementation
Slicing stories with focus on customer benefits and variants. (Source: SwissQ)

Conclusion

No matter what principle or methodology you choose for splitting epics, features, or stories, be bold and eager to learn! Instead of neglecting the theories of slicing items you should remember the few questions above. If you have questions about this topic, would like to learn more, or need help with specific projects, don’t hesitate to contact us. We have a wide range of training courses in our Academy and are happy to help you with specific projects with our Product Engineering Services.

0 thoughts on “Backlog-Items and the «Art of Splitting / Slicing»”


Leave a Reply