What makes something an Increment
The Scrum Guide is precise here: an Increment only exists once a Product Backlog item meets the team's Definition of Done. Multiple Increments may be created within a Sprint, and the sum of the Increments is presented at Sprint Review, supporting empiricism. But the Increment is a moment of verified completion, not a milestone on a calendar.
This is why the Scrum Guide states that an Increment must be usable regardless of whether the Product Owner decides to actually release it. Usability, not release decision, is what defines it. The decision to ship is a business call; the Definition of Done is a quality call, and they are separate.
Multiple Increments, one Sprint
A single Sprint can produce several Increments as different Product Backlog items reach the Definition of Done throughout the Sprint, not only on the last day. Work does not need to wait until the Sprint ends to be considered done; the Scrum Guide explicitly allows evaluation of an Increment as soon as it meets the Definition of Done.
This matters for flow: teams that batch all their 'finishing' work into the final two days of a Sprint have usually missed opportunities to inspect and adapt earlier, when there was still time in the Sprint to react.
Increments and release decisions
Whether an Increment gets released to users is a decision made by the Product Owner, informed by business, legal, or market considerations that have nothing to do with the Increment's technical readiness. A Scrum Team can, and often should, produce several usable Increments before deciding to actually ship one to customers.
This separation lets teams decouple 'is it done' from 'should we release it now,' which is what allows continuous delivery practices to sit comfortably on top of Scrum without contradicting the framework.
- An Increment must meet the Definition of Done to exist at all
- An Increment must be usable, whether or not it is actually released
- A Sprint can produce more than one Increment
- Release timing is a Product Owner decision, separate from Done
Anti-patterns
Calling something an Increment when it has not met the Definition of Done, usually under Sprint-end time pressure, is the most damaging anti-pattern because it quietly erodes the meaning of Done across the whole team. Another is assuming an Increment must be released to count; the Scrum Guide never ties the two together.
Treating Increment creation as something that only happens on the last day of the Sprint is also a mistake; it discourages incremental delivery within the Sprint and pushes all the risk of integration and testing to the very end.
How it connects to the rest of Scrum
The Increment is inspected at Sprint Review against the Sprint Goal and Product Goal, and it depends entirely on the Definition of Done for its meaning. Over many Sprints, the accumulated, verified Increments are what actually move the product toward its Product Goal, which is the long-term, more durable commitment behind the Product Backlog.
Frequently asked questions
Does an Increment have to be released to users?
No. The Scrum Guide requires an Increment to be usable, not released. Whether it is actually shipped to users is a separate decision made by the Product Owner based on business, legal or market factors.
Can a Sprint produce more than one Increment?
Yes. The Scrum Guide states multiple Increments may be created within a Sprint as items reach the Definition of Done, and the sum of Increments is presented at Sprint Review, not just the last one finished.
What is the difference between an Increment and a Product Backlog item?
A Product Backlog item is a description of desired work. It becomes part of an Increment only once it meets the Definition of Done; before that, it is still just planned or in-progress work, not a real Increment.
How does the Increment relate to the Product Goal?
Each Increment is additive to prior ones, and the Scrum Guide describes them together as forming a coherent whole. Over time, the accumulation of verified Increments is how a Scrum Team actually makes progress toward its Product Goal.