The Increment: What It Really Means in Scrum
Ask ten Scrum practitioners what the Increment is and you will get ten different answers. Some will say it is the sum of work completed in the current Sprint. Others will say it is the potentially shippable product at the end of the Sprint. A few will conflate it with the release. The 2020 Scrum Guide is precise on this point, and the precision matters: the Increment is the sum of all completed Product Backlog Items (PBIs) in the current Sprint plus the value of all prior Increments.
The Definition: Cumulative, Not Just Current
The Increment is cumulative. Each new Sprint adds to the Increment — it does not replace it. If Sprint 1 produced a working login module and Sprint 2 adds a working dashboard, the Increment at the end of Sprint 2 is the login module plus the dashboard, together functioning as a coherent whole. This cumulative nature is not a technicality — it is the mechanism by which Scrum delivers a potentially releasable product at the end of every Sprint, regardless of how many Sprints have preceded it.
The Definition of Done: The Gate
Not everything completed in a Sprint counts as part of the Increment. A PBI becomes part of the Increment only when it meets the Definition of Done (DoD). The DoD is a formal description of the quality standards that a PBI must meet before it can be considered complete. It might include: code reviewed, unit tests passing, integration tests passing, documentation updated, and accepted by the Product Owner.
Work that does not meet the DoD is not part of the Increment. It is unfinished work that returns to the Product Backlog. This is a hard rule in Scrum, and for good reason: including undone work in the Increment degrades the reliability of the "potentially releasable" claim. If the Increment contains items that have not met the DoD, the team cannot honestly say that the product is in a releasable state.
Potentially Releasable vs. Released
Scrum requires that the Increment be potentially releasable at the end of every Sprint. It does not require that the Increment be released. These are fundamentally different things, and confusing them is a common source of tension between development teams and business stakeholders.
"Potentially releasable" means that the Increment is in a state where the organisation could choose to release it without additional technical work. It is a statement about the quality of the product, not about the business decision to release. The decision to release — or not to release — is the Product Owner's. A team might produce a potentially releasable Increment every Sprint for six months without ever releasing to production, because the business is waiting for a specific feature set or regulatory approval.
Why This Matters for Multi-Team Programmes
The Increment becomes especially important — and especially complicated — in multi-team programmes. When multiple Scrum teams are working on the same product, the Increment at the end of each Sprint must be the integrated output of all teams, not just the sum of what each team individually produced.
This means integration cannot wait until the end of the programme. Teams must integrate frequently — ideally at least once per Sprint — so that the cumulative Increment remains coherent and potentially releasable. Programmes that defer integration until late in the delivery cycle frequently discover incompatibilities, interface issues, and quality problems that are far more expensive to fix at that stage than they would have been if caught earlier.
Common Misunderstandings
Misunderstanding 1: The Increment is what the team built this Sprint. Correction: the Increment is the sum of everything built this Sprint plus all prior Sprints that meets the DoD.
Misunderstanding 2: If we're not releasing, there's no need to have a releasable Increment. Correction: the point of the releasable Increment is to preserve optionality — the business can release when ready, not only when the team is ready.
Misunderstanding 3: The DoD is aspirational — it's fine if some items don't quite meet it. Correction: the DoD is a hard gate. Items that do not meet it are not part of the Increment.
Misunderstanding 4: Each team's output is their own Increment. Correction: in a multi-team product, there is one Increment — the integrated output of all teams.
Getting the Increment right is not a theoretical concern. Teams that have a clear, shared understanding of the Increment — and a robust Definition of Done — consistently deliver higher-quality products, with fewer surprises at release time, than teams that treat the Increment as an abstraction.
XNM Consulting supports organisations implementing Scrum and scaled agile frameworks across complex programmes. Learn more on our Program and Project Delivery page.