An Increment is a concrete stepping stone toward the Product Goal. Each one is additive to every prior Increment and thoroughly verified, so that all Increments work together. Its commitment is the Definition of Done.
Concrete, and a step rather than a report
An Increment is something that exists and works. A design, a document, a demonstration environment and a branch waiting to be merged are none of them Increments, however much effort they represent, because empiricism needs something real to inspect and adapt from.
The Guide also asks that an Increment be usable, which is what makes releasing it a decision rather than a project. Usable is not the same as released and it is not the same as complete. It means the thing works well enough that it could be put in front of the people it was built for, so the only remaining question is whether now is the right moment.
Stepping stone is the other half. Each Increment is a step toward the Product Goal, so the test of one is not how much was built but whether the product is measurably closer to the objective the backlog was ordered around.
Additive and thoroughly verified
Additive means each Increment builds on what came before rather than replacing it, so the product accumulates instead of being rebuilt every few Sprints. Thoroughly verified means the combination has been checked, not just the new part, and that is the harder half of the sentence.
A feature that works on its own and breaks the one shipped two Sprints ago has not produced an Increment. It has produced a regression. Both words matter most when several teams contribute to one product, where each team can meet its own standard and the product can still fail, because nobody verified the parts against each other.
Done, or not part of the Increment
Work cannot be considered part of an Increment unless it meets the Definition of Done. That line is tested more than anything else in this area, because an item which is functionally complete and fails one criterion of the Definition of Done is not part of the Increment, and it returns to the Product Backlog for future consideration.
The rule is what stops undone work accumulating. A team allowed to count nearly finished items carries a debt nobody has measured from Sprint to Sprint, and it only becomes visible when somebody tries to release. Returning the item is not a punishment, and it is the only way the remaining effort stays on a list that gets ordered.
An Increment may therefore contain fewer items than were selected during Sprint Planning. That is ordinary, and it is not a failed Sprint if the Sprint Goal was met.
Multiple Increments within one Sprint
Multiple Increments may be created within a Sprint, and the sum of them is presented at the Sprint Review. The wording rewards a second reading, because the Guide is describing what gets inspected rather than what gets produced. A team that integrates and verifies daily is creating many Increments in a Sprint and presenting the whole.
There is no number in the Guide, 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 has produced nothing for anyone to inspect, which is the failure the artifact exists to prevent.
The Sprint Review is not a release gate
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, and treating the review as the moment value is allowed out converts a feedback event into a checkpoint, which lengthens the loop the Sprint was meant to shorten.
The Sprint Review exists to inspect the outcome and work out what to do next with the people affected by the product. It is a working session rather than an approval, and what comes out of it is an adjusted Product Backlog rather than a signature.
When to release is a decision the Guide leaves alone. It 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 describing it as potentially releasable.