Shipping a Real Increment Every Sprint: A Beginner-Friendly Explainer
In Scrum, the Increment is the sum of all completed work across the current Sprint and all previous Sprints. Every Sprint must produce at least one Increment, and every Increment must meet the team's Definition of Done. The Increment must be usable -- it must be in a condition where it could, in principle, be released to users -- even if the Product Owner decides not to release it.
This standard is stricter than many teams realise. An Increment that is feature-complete but has failing tests, known defects, or incomplete documentation does not meet the Scrum standard. Neither does an Increment that works in a development environment but has not been validated in a staging environment. This guide explains what a real Increment looks like and how to consistently produce one.
What a Real Increment Requires
A clear Definition of Done that reflects "done" at a product quality standard, not "done with development." The Definition of Done is the shared understanding of what "complete" means for a Product Backlog Item. It should include: code reviewed, automated tests passing, no known defects, integrated into the main codebase, deployed to a staging environment, and documentation updated. If an item has been coded but not tested, it is not done.
Sprint planning that is realistic about what can be done to the Definition of Done, not optimistic about what can be coded. A Sprint Backlog that contains more items than the team can complete to the Definition of Done will not produce a complete Increment. During Sprint Planning, the team should ask: can we complete each of these items fully by the end of the Sprint?
A Sprint Review that demonstrates the Increment against the Definition of Done, not just a demo of new code. The Sprint Review is an inspection of the Increment by the Scrum Team and stakeholders. If items were not completed to the Definition of Done, they should not be presented as completed -- they should be returned to the Product Backlog.
Common Ways Teams Fall Short
"Done" is defined as "coding is complete." When testing, integration, and documentation are treated as separate activities that happen after the Sprint, the Increment at the end of each Sprint is actually a partial product that has never been validated as working.
The team carries technical debt from the Definition of Done. When the Definition of Done is aspirational rather than enforced, items accumulate testing debt, integration debt, and documentation debt. The Increment that the team presents is the development-environment version of the product, not the deployable version.
The Sprint goal is a list of features rather than an outcome. A Sprint goal that reads "add search filter, update notifications, and fix three bugs" is a feature list, not a goal. When the Sprint goal is a list, any subset of the list counts as a partial win. When the Sprint goal is an outcome -- "users can filter search results and get notified of relevant updates" -- it is either achieved or not.
XNM supports public-sector organisations in establishing effective agile delivery practices. Reach out to XNM's program & project delivery advisory team for support with building a disciplined Scrum practice in your organisation.