An Increment has to be usable
An Increment is a concrete stepping stone toward the Product Goal, and it must be usable. Work cannot be considered part of an Increment unless it meets the Definition of Done. Multiple Increments may be created within a Sprint, and an Increment may be delivered to stakeholders before the end of the Sprint.
Why it is like this
Tying the Increment to usability rather than to the Sprint boundary is what makes the Sprint Review a working session rather than a demo of something that cannot ship.
Not to be confused with
One deliverable per Sprint, released at the end. The Guide explicitly allows several Increments inside a Sprint, and says the Sprint Review should never be considered a gate to releasing value.
In practice
Work that is code-complete but unreviewed and untested is not an Increment, however finished it looks on the board. It is undone work in a Sprint that is about to end.
Source: The Scrum Guide, November 2020 (Schwaber & Sutherland) — Increment. Read on .
The Scrum Guide is published by Ken Schwaber and Jeff Sutherland under CC BY-SA 4.0. These cards are independent commentary written in our own words, not a derivative of the Guide's text. ytyk.org is not affiliated with, endorsed by or licensed by Scrum.org, Scrum Alliance or the Guide's authors.
Predict Check yourself
A team finishes three items on day 4 that meet the Definition of Done. Must they wait for the Sprint Review to release them?
Show the answer
No — multiple Increments may be created within a Sprint, and the Review is not a gate to releasing value.
The Guide says so in as many words. Teams that hold finished work for the Review have turned the Review into the release gate it tells them not to be.