Does it fit in a Sprint?
Basic
difficulty
Stage 2
Agile IQ® Level
Estimation
Metrics
Introduction
All work that goes into a Sprint needs to achieve the Definition of Done by the end of the Sprint. This ensures all work in the Sprint delivers business value by the end of the Sprint.
But what do you do if work is too large to fit into a Sprint?
Compare the size to other items
Have you delivered something similar? Is it about the same size in terms of work the team needs to do to meet the Definition of Done? If so, then the Product Backlog item is small enough to fit into the Sprint.
If the item can’t be delivered as currently described, then the team needs to break it down into smaller pieces. Each piece needs to be able to be completed, and achieve the Definition of Done, by the end of the Sprint.
How much work is needed to meet the Definition of Done?
By default, all work taken into a Sprint has to meet the Definition of Done by the end of the Sprint. For software teams, this typically means for each Product Backlog item:
- Do the design, ensure the architecture and security meets the nescesary standards.
- Build the code.
- Ensure there are no severity level 1 or 2 defects for functional and integration testing.
- Update the documentation.
- Integrate the code to the main branch.
- Deploy the code to production.
For a communications and marketing team, this might include:
- Ensure the copy is in plain-English
- Use the corporate fonts, style guide and templates
- Peer review the copy for grammar and spelling.
- Store the document in the corporate document repository.
Sometimes, doing all this work might not fit into a Sprint.
Don’t Waterfall large Backlog items
Rather than separate out the build in one Sprint and then the testing in another Sprint (this is called “Waterfall”), we slice the feature into “vertical slices”.
Don't Waterfall your Sprints
If you're breaking up Backlog items by task, so that you're doing development in one Sprint and then testing in another, you're Waterfaling your Sprints. Try, instead, to break up large backlog items by Feature. This is known as 'vertical slicing''.
Vertical Slicing
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.
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/
