Splitting Product Backlog Items

There are several reasons why a Product Backlog Item should be split. The very first reason that comes to my mind is because you notice it is huge, or at least significantly larger than what can be developed in a single sprint. To be more precise, reasons may be because it doesn't follow the INVEST principles—INVEST is an acronym for Independent, Negotiable, Valuable, Estimable, Small and Testable. It is a mnemonic device for agile software projects created by Bill Wake as a reminder of the characteristics of a good-quality Product Backlog Item.

Sometimes it's easy to tell where an item should be split. Sometimes, that task is harder than it seems. Product Backlog refinement or planning meetings are the perfect times to split them.

I learned a method to split Product Backlog Items from Mike Cohn, agile guru and co-founder of the Scrum Alliance. It’s called the S.P.I.D.R. method, which stands for Spikes, Paths, Interfaces, Data and Rules. These are the 5 ways that can help you split your Product Backlog Items:

Spikes

Divide an item at a knowledge spike, or a milestone within your research. It's a point at which you may find new ways to further split the item.

Paths

Consider every path within the item as separate work. You can do a simple flowchart of the different paths within the Product Backlog Item, where every path would be a different item. You can also expand a big step within a given item, then convert it to a new one.

Interfaces

Split the Product Backlog Item by interface if those multiple interfaces make the story significantly larger to develop. You can also split an item by technology used or version.

Data

Split the item by the data types that must be supported. Or, you can first implement the part of the item that works with more frequent data, and then another part that works with less frequent data.

Rules

If a Product Backlog Item is born large because of business rules or technology standards that must be supported, consider lowering the support expectations for these rules in the initial item. Then consider supporting those additional business rules in the following items.

Other patterns that you can follow to split Product Backlog Items are the ones I learned from a blog post by Richard Lawrence. These include:

  • Workflow Steps pattern
  • Business Rule Variations pattern
  • Major Effort pattern
  • Simple/Complex pattern
  • Variations in Data pattern
  • Data Entry pattern
  • Operations pattern
  • Defer Performance pattern
  • Break Out a Spike pattern

Some of them, such as “Workflow Steps,” “Business Rule Variations,” “Variations in Data,” “Data Entry” and “Break Out a Spike” patterns, were already covered in the S.P.I.D.R. method. The rest are:

Major effort pattern

Split the item so that most of the effort will go towards implementing the first item.

Simple/complex pattern

First, attempt to define acceptance criteria for a simple version of the item. Then, consider developing the more complex versions.

Operations pattern

Try to split along the lines of operations and procedures. You might look at this in terms of CRUD (create, read, update and delete) scenarios.

Defer performance pattern

Sometimes you can start with thinking about making the base work, and afterwards focus on its performance.

Well folks, I hope these techniques help you figure out how to breakdown your unwieldy Product Backlog Items. See you around, and don’t forget—keep calm and be Agile.

You may also like:

A Product Owner’s To Do List in Perfect Development

Our last article covered the Perfect Development Agenda. Now we will start with the first To Do list: the Product Owner’s. There are four To…

Deviations from Optimal Planning – Backlog Not Ready

We spoke about Optimal Planning, so now let’s dig into the deviations from it. The first one is if the Backlog is not ready. If…

Estimate and Select from the Top of the Product Backlog

You have learned how to “play” Planning Poker and what Story Points are. Let’s have a look at the next three rules. If Developers determine…