Slicing Stories
Basic
difficulty
Stage 2
Agile IQ® Level
Estimation
Practices
Agile Manifesto
Framework
Introduction
When work doesn’t get finished in a Sprint, the temptation is to “roll it over” into the next Sprint. A better approach is to learn to slice work so that it does fit into a Sprint.
Slicing Backlog items like a cake – thin, vertical slices, is considered “best practice”.
Each slice of the large Backlog Item needs to achieve the Definition of Done by the end of the Sprint. Keep slicing until the item is small enough to do so.
Estimation & slicing are an essential part of an Agile Mindset
Estimation and slicing work into smaller pieces is an important factor in getting work done in a short timeframe: "Deliver [work] frequently ... with a preference to the shorter timescale."
Don't slice Stories by your team's roles
Many teams are used to task-based work. When moving to agile, they typically just change ‘tasks’ to ‘stories’, but still deliver in the same way. Capability-based slicing of Product Backlog items is an anti-pattern and often leads to Stories being delivered over multiple Sprints.
Slice Stories by its functionality and integrate each Story as you go. Put tasks against each Story to reflect who will do what, how the UX will be done, how the analysis will work, building and testing, etc.
Vertical Slicing is Best Practice
What is vertical slicing?
The term “vertical slice” refers to a cross-sectional slice through the layers that form the structure of the software code base. It is mostly used in Scrum where the work is planned in terms of features. For example, as a very basic approach, a software product may consist of three layers (or components):
- Data access layer (bottom)
- Business logic layer (middle)
- User interface layer (top)
Why not use 'horizontal' slicing?
Horizontal slicing has a number of disadvantages to vertical slicing.
- Reduced transparency: Progress isn’t visible to customers until the last slice is delivered and integrated.
- Higher dependencies: Each layer is dependent on the previous layer. If an error isn’t found until the UI layer is delivered, rework might extend all the way back to the database layer.
This makes vertical slicing a preferred practice over horizontal slicing.
Slice large PBIs like cake
This is where the ‘multi-layer cake’ metaphor was born. First espoused by Bill Wake (2003), he suggests:
Think of a whole system as a multi-layer cake, for example, a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice the cake vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it 'right'), but a full database layer (for example) has little value to the customer if there is no presentation layer.
How small should the slices be?
While there is no ‘perfect’size for a Backlog item, to promote the best transparency possible, try slicing a Backlog item so that it can be delivered against the Definition of Done in 2-3 days.
Actions
In your Retrospective:
- Assess what items achieve Done and which ones don’t.
- What items continue to not get to Done in the Sprint? Do they simply start too late in the Sprint for their size? Is there a similar pattern to the items that don’t make it to Done in the Sprint?
- Agree on a method to make items smaller when they don’t achieve Done.
References
1. Wake, B. (2003). INVEST in Good Stories, and SMART Tasks. Xp123. Online at: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
All fields are required.
