Slicing backlog items with SPIDR
Moderate
difficulty
Stage 3
Agile IQ® Level
Backlog Items
Product Backlog
Introduction
Backlog items need to be small enough so they can be delivered within a single Sprint. Sometimes, though, they’re just too big.
When items are too big to be delivered within a single Sprint, the team must slice the item into smaller pieces. SPIDR, by Mike Cohn, is a useful mnemonic to help teams work out ways to break large backlog items into smaller ones.
- Spikes – A research activity can give you the knowledge you need to split a complex story.
- Paths – If a user can do something in multiple ways, that’s a great area for splitting.
- Interfaces – Splitting your story by browser, or hardware, or deliver a complex interface in iterations.
- Data – You may be able to deliver value in an iteration by focusing on one type of data.
- Rules – Relaxing support for the rules in an iteration can make large stories smaller.
SPIKES
When the team doesn’t know how to slice a Backlog item into smaller pieces a “spike” is a useful activity.
What is it?
- A research activity that gives you the knowledge you need to split a complex story.
- A timeboxed research task, typically no more than 2 hours as a timebox.
Actions to try
- Do some research and analysis.
- High-level design.
- Investigation.
- Look at the code.
- Talk to others to see how they’ve sliced this kind of work before.
- Design Thinking to understand the purpose and outcome of the Backlog item.
What happens by the end of the timebox?
- The team has a solution to slice the item into smaller pieces.
Watch out for
- Ensure the research is kept within the timebox.
- Ensure the research results in a choice of how to slice the Backlog item.
PATHS
Defining the steps a user takes can help a team slice large items into smaller pieces.
What is it?
- If a user can do something in multiple ways, that’s a great area for splitting.
Actions to try
- Define the user with Personas.
- Draw out the user’s paths.
- Create a User Journey.
- Define Product Backlog items by each step.
Watch out for
- Don’t create UX-stories to do this analysis and design. This is just backlog refinement.
Interfaces
Split a large Product Backlog item by browser type, device type, or hardware, or by parts of a complex user interface (UI).
What is it?
- If the UI has many parts, create a Product Backlog item for each one of those parts.
Actions to try
- Sketch out or wireframe the UI.
- Identify whole features in the UI.
- Define the types of devices – PC, tablet, mobile – and create an item out of each type.
- Define each section as a separate Product Backlog item.
Watch out for
- Don’t slice the UI into its technical components. This only increases the complexity and places a burden on downstream integration.
Data
You may be able to deliver value in an iteration by focusing on one type of data.
What is it?
- Where the data is complex and large, consider a type of data to work on first.
Actions to try
- Slice by geographical region.
- Slice by date.
- Slice by role type.
- Slice by user type, e.g. Amazon Prime vs. non-Amazon Prime customer.
What to watch out for
- Ensure that each subsequent slice of data is integrated into the others as part of the acceptance criteria.
Rules
Relaxing support for the rules in an iteration can make large stories smaller.
What is it?
- Business rules can be complex. Identify and create Product Backlog items by smaller sets of those rules.
Actions to try
- Incrementally add business rules
- Iteratively add business rules
What to watch out for
- Ensure that each subsequent slice is still ‘horizontal’. Don’t slice by the technical components of the system.
