The Increment: a usable step, not a pile of finished tasks

At the end of a Sprint, a team reports that 90 per cent of everything is done. A stakeholder asks to see it, and discovers that the finished parts do not work together, because nobody has joined them up. Ninety per cent done and ninety per cent usable are very different claims. The Increment is the Scrum word that forces the second.

The Guide's definition

An Increment is a concrete stepping stone toward the Product Goal. The Guide gives it three properties.

• Additive. Each Increment is additive to all prior Increments.
• Thoroughly verified. It is checked, so that all Increments work together.
• Usable. In order to provide value, the Increment must be usable.

Usable is the demanding word. Code that passes its own tests but cannot be run, a screen that looks right but is not connected to anything, a service that works on one developer's machine: none of these is usable. The test is whether someone could use it, whether or not anyone yet does.

The Increment is also the artifact that carries a commitment, the Definition of Done. The Guide says work cannot be considered part of an Increment unless it meets the Definition of Done, and that the moment a Product Backlog item meets it, an Increment is born. This is why our post on the Definition of Done and this one belong together: the first sets the bar, and the second names what clears it.

One Sprint, several Increments

The Guide allows more than one Increment in a Sprint, and says the sum of the Increments is presented at the Sprint Review, supporting empiricism. So an Increment is not "the thing at the end of the Sprint". Every time an item meets the Definition of Done and joins what already exists, the Increment grows. A team that finishes one item on day three has an Increment on day three.

That has a practical effect on the Sprint. Teams that keep their work in progress small and finish items one at a time have something usable at every moment. Teams that start everything on the first day and finish everything on the last have nothing usable until then, and nothing to show if the Sprint is interrupted.

Done is not released

The Guide separates two ideas that are often merged. An Increment may be delivered to stakeholders prior to the end of the Sprint, and the Sprint Review should never be considered a gate to releasing value. The Increment is about what exists and is verified. Release is a separate decision about when to put it in front of users, and it belongs to the Product Owner and the organisation's practices.

Three situations show the difference.

• Done, not released. The Increment is verified and usable, but the Product Owner decides to hold it until a related feature is ready. That is a business decision, and nothing is wrong with the work.
• Released, not done. A team pushes something to users that skips the checks in the Definition of Done. This is the case the Definition of Done exists to prevent.
• Neither. An item is nearly finished and not verified. It is not part of an Increment. The Guide says an item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review, and returns to the Product Backlog.

The SBOK's phrasing

The SBOK® Guide's vocabulary is a little different. It speaks of Sprint deliverables: at the end of each Sprint, a product increment or deliverable is completed, which should have all the features and functionality defined in the user stories included in the Sprint, and should have been tested successfully. It describes these as potentially shippable and says such deliverables are what it means by "Done". It also notes that rejecting a few stories at the review is not a rejection of the whole increment, and the increment could potentially still be shippable.

The key phrase is "potentially shippable". It means that the team could ship if the business wanted to, not that it must. This is close to the Guide's idea of usable and verified.

One difference is worth noting. In the SBOK, the Product Owner accepts or rejects each story against its acceptance criteria in the Sprint Review, and acceptance is what makes a story Done. In the Scrum Guide, meeting the Definition of Done is what makes an item part of the Increment, and the review is an inspection and not an approval step. Both lead to the same discipline: no partial credit.

A worked example

Here is an invented case. A team has five stories in its Sprint and a Definition of Done that includes code review, automated tests, deployment to a test environment, and updated documentation.

• On day four, "find a tutor" meets all four conditions. An Increment exists.
• On day seven, "book a lesson" is built and tested but not deployed to the test environment, because the environment is broken. It is not in the Increment. The impediment goes on the board.
• On day nine the environment is fixed and "book a lesson" is deployed. The Increment now contains two stories, and they have been verified together.
• On the last day, "pay for a lesson" is demonstrably working but its documentation has not been updated. It does not count. At the review the team says so, and the story goes back to the top of the Product Backlog.

The Sprint Review shows two stories, honestly. The stakeholders know exactly where the product stands, and the Product Owner has a clear picture for the next Sprint Planning. That is the Increment doing its job.

Common mistakes

• Counting done-except-for items. "Done except for testing" is not done.
• Integrating at the end. If the pieces are joined only in the last days, the verification the Guide requires happens too late to fix anything.
• Treating the Increment as the release. They are linked but separate decisions.
• Showing what is not Done at the review. It confuses stakeholders about the state of the product.
• A Definition of Done too weak to mean usable. If "done" does not include running the thing in a realistic environment, the Increment may not be usable.
• Forgetting that it adds up. An Increment that breaks an earlier one is not additive. Regression checks belong in the Definition of Done.

The Agile Manifesto states the measure plainly: working software is the primary measure of progress.

How to practise it

An Increment becomes real at the Sprint Review, when someone has to say what is and is not done. In the simulator, the developers demonstrate the increment to the sponsor, and the Product Owner accepts or rejects each story against the Definition of Done.