Increment
A concrete, inspectable, usable stepping stone toward the Product Goal, created by adding to prior Increments and meeting the Definition of Done.
What it means
An Increment is additive: every one builds on those before it, and multiple Increments can be created within a single Sprint. Regardless of how many are produced, all of them are inspected together at the Sprint Review.
Work cannot be considered part of an Increment unless it meets the team's Definition of Done. This ensures that quality does not erode even when scope or timelines are under pressure.
Common mistakes
An Increment does not have to be released to users immediately; the Product Owner decides when and whether to release. What matters is that it is in a releasable state and usable.
Example
By the end of the Sprint, the team has an Increment that includes a working checkout flow, tested and deployable, even though it is released to customers a week later.
What counts as an Increment
An Increment is a usable step toward the Product Goal, not a demo, not a branch and not a document describing work in progress. If a stakeholder could use it as it stands, it qualifies. If it needs a further round of testing, integration or sign off, it does not.
- It meets the Definition of Done in full
- It adds to every Increment created before it
- It is usable and in a releasable state, whether or not it ships
- It is inspected at the Sprint Review together with the other Increments of that Sprint
How many Increments in a Sprint
There is no single Increment per Sprint rule. A team can create several inside one Sprint and release each one the moment it is Done. The Sprint Review is where all of them are inspected together, so releasing early does not remove the need for that conversation.
Increment examples
- A checkout flow that is tested, deployable and behind a feature flag
- A reporting endpoint that returns real data and is documented for its consumers
- A migration script that has run against production sized data and is reversible