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?
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.
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:
For a communications and marketing team, this might include:
Sometimes, doing all this work might not fit into a Sprint.
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”.
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):
Horizontal slicing has a number of disadvantages to vertical slicing.
This makes vertical slicing a preferred practice over horizontal slicing.
This is where the ‘multi-layer cake’ metaphor was born. First espoused by Bill Wake (2003), he suggests:
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.