An Increment is a concrete stepping stone toward the Product Goal. Each one is additive to every prior Increment and thoroughly verified, so all Increments work together, and the Definition of Done is the commitment attached to the artifact. The words concrete and additive carry most of the teaching, because a team can produce a great deal of work in a Sprint and still produce no Increment.
An Increment is something that exists and works
Four things that often get called Increments are a design, a document, a demonstration environment and a branch waiting to be merged. None of them is an Increment, however much effort it represents, because empiricism needs something real to inspect, and a branch nobody has merged cannot be inspected as part of the product.
The Guide also asks that an Increment be usable. Usable describes the state of the work and says nothing about whether anybody has released it, so a usable payments feature sitting behind a flag is still an Increment. What usable rules out is work that would need another round of effort before anyone could use it, and that is what turns releasing into a decision about timing.
Usable settles one half of the definition, and stepping stone is the other. That half is easier to say and harder to apply. The test of an Increment is whether the product is measurably closer to the Product Goal, so a Sprint that produced forty finished items and moved the product nowhere has produced finished items without producing a step.
Additive and thoroughly verified
Additive means each Increment builds on the ones before it, so the product accumulates across Sprints, and a team that rewrites the same checkout flow every quarter has motion without accumulation. Thoroughly verified goes further, because the verification covers the combination, which includes every part built in earlier Sprints.
A new rate limit on a payments API that works on its own and breaks the client library shipped two Sprints ago has produced a regression rather than an Increment. Both words matter most when several teams contribute to one product, because each team can meet its own standard while the product still fails, and the missing step is verifying the pieces against each other.
Only work that meets the Definition of Done is part of an Increment
The Guide rules this out directly, saying that work cannot be considered part of an Increment unless it meets the Definition of Done. An item that is functionally complete and fails one criterion of the Definition of Done is therefore outside the Increment, and it returns to the Product Backlog for future consideration. The usual example is an internal admin tool that works and has not been through the accessibility check its Definition of Done requires.
That rule is what stops undone work accumulating. A team allowed to count nearly finished items carries a debt nobody has measured, and the debt stays invisible until somebody tries to release. Returning the item to the Product Backlog puts the remaining effort back on a list that gets ordered, which is the whole purpose of the rule.
An Increment may therefore contain fewer items than the Developers selected during Sprint Planning. A Sprint that ends that way has still succeeded if the Sprint Goal was met, because the commitment was to the objective and the items were only the plan for reaching it.
What the Scrum Master does about the Increment
A Sprint that delivers fewer items and still meets its Sprint Goal needs somebody willing to say so, and the Guide puts that work closest to the Scrum Master. The accountability is for helping the Scrum Team focus on creating high value Increments that meet the Definition of Done. Helping a team focus is some distance from owning what it produces, since the Developers instil quality by conforming to the Definition of Done and the Product Owner decides when an Increment reaches users.
The service works against two habits in particular. The first is a team presenting work it knows misses the Definition of Done, because the Sprint looks better that way, and the answer there is transparency. The second is a Sprint Review treated as a release gate, which usually comes from outside the team, so clearing it is service to the organisation.
Multiple Increments within one Sprint
Multiple Increments may be created within a Sprint, and the sum of them is presented at the Sprint Review. That sentence repays a second reading, because it describes what gets inspected and leaves the number produced open. A team that integrates and verifies a data pipeline change every day is creating many Increments in one Sprint and presenting all of them together at the review.
The Guide sets no number, in either direction. What it insists on is that anything called an Increment meets the Definition of Done and is usable, so a Sprint ending with nothing usable leaves the Sprint Review with nothing to inspect, which is the failure the artifact exists to prevent.
When an Increment may be released
An Increment may be delivered to stakeholders before the end of the Sprint. Nothing in Scrum asks a team to hold finished, usable work until a meeting, so a billing job fixed on the third day of a Sprint can go out on the third day. Treating the Sprint Review as the moment work becomes releasable turns a feedback event into a checkpoint, and that lengthens the loop the Sprint was meant to shorten.
The Sprint Review exists to inspect the outcome of the Sprint and work out what to do next, with the people the product affects in the room. What comes out of it is an adjusted Product Backlog, so a review that ends in a signature and no change to the backlog has been run as an approval meeting.
When to release is a decision the Guide leaves alone. The decision belongs with the Product Owner and depends on the product, the market and the risk of the change, which is one reason the 2020 edition asks for an Increment that is usable rather than potentially releasable.