Increment | Agile Scrum Master
Increment is a usable, valuable step toward the Product Goal that meets the Definition of Done and can be inspected to support adaptation. It makes progress transparent by ensuring work is integrated and complete, not partially finished, and it enables better decisions in Sprint Review and Product Backlog ordering. Key elements: Definition of Done, integration, usable state, transparency, inspection in Sprint Review, and the option to release.
Purpose of Increment
Increment is a concrete, usable step toward the Product Goal. It represents the sum of all Product Backlog items completed during a Sprint and the value of the Increments of all previous Sprints. Increment is the basis for inspection and adaptation.
Increment exists to make progress empirical: working results are visible, inspectable, and suitable for decision-making. It prevents “almost done” work from being mistaken for value by requiring integrated, verified outcomes that meet the Definition of Done. A usable Increment shortens feedback loops because stakeholders can inspect what works, the Scrum Team can learn from real behavior and constraints, and the Product Backlog can be adapted based on evidence rather than assumptions.
Definition of Done and quality
Increment must meet the Definition of Done. The Definition of Done is the commitment for the Increment and defines the quality measures required for the product. Without a meaningful Definition of Done, “done” becomes negotiable, progress becomes ambiguous, and inspection becomes unreliable.
Quality is a constraint that protects learning. It includes whatever is necessary for real use in your context, such as security, performance, operability, maintainability, and support readiness. When quality is deferred, the product accumulates hidden work, feedback arrives late, and decisions become less reliable because the Increment is not truly usable.
Creating and inspecting Increment during a Sprint
Increment is created as Developers implement selected Product Backlog items and integrate them into the product. Integration should happen continuously so the product stays coherent and usable throughout the Sprint, not only at the end.
Increment is inspected in Sprint Review, where stakeholders and the Scrum Team examine what was built and what was learned. Inspection is meaningful only when the Increment is usable; otherwise the conversation shifts to opinions, slides, and promises instead of evidence. The outcome of inspection is adaptation, such as updated Product Backlog ordering, clearer assumptions, and better next-step decisions toward the Product Goal.
The Increment is one of the three Scrum artifacts, alongside the Product Backlog and Sprint Backlog. Its associated commitment is the Definition of Done, which makes the Increment’s quality and readiness transparent and keeps inspection reliable. This relationship supports the Scrum pillars:
- Transparency - Make the Increment’s real state visible using a shared Definition of Done.
- Inspection - Inspect usable working results and their quality, not activity or intent.
- Adaptation - Change backlog ordering and next steps based on what the Increment and feedback reveal.
In Scrum, Increments are created through collaborative work during the Sprint. The process typically involves:
- Selecting Product Backlog Items - Choose items that support the Sprint Goal and maximize learning per unit of effort.
- Developing and integrating - Build in small slices and integrate frequently to reduce batch size and late surprises.
- Verifying against the Definition of Done - Count work as part of the Increment only when it meets agreed usability and quality criteria.
- Reviewing and demonstrating - Inspect the usable Increment with stakeholders to gather feedback and adapt.
Key Characteristics of an Increment
- Usable - Ready for real inspection and could be released, even if not released immediately.
- Integrated - Works with all prior Increments so the product stays coherent and avoids hidden merge debt.
- Meets the Definition of Done - Applies consistent quality criteria so progress is comparable over time.
- Additive - Moves the product toward the Product Goal by adding capability or improving existing capability.
- Transparent - Makes readiness, risks, and constraints visible so decisions are grounded in evidence.
Common technical enablers for effective Increments include:
- Continuous integration - Keep integration batches small and expose problems early while they are cheap to fix.
- Automated testing - Provide fast regression feedback so usability and quality remain sustainable as the product grows.
- Small vertical slices - Deliver end-to-end scenarios that can be validated, not partial layers that delay learning.
- Deployment safety - Use techniques such as feature toggles and staged rollout options to limit blast radius.
Multiple Increments and release decisions
There can be multiple Increments within a Sprint. Each time work meets the Definition of Done, it strengthens transparency and reduces risk by shrinking batch sizes and enabling earlier inspection.
Releasing is a business decision, but releasability is a product property. A usable Increment may or may not be released immediately, yet it should be releasable without additional hidden steps. If work requires late integration, approvals, or stabilization after the Sprint, the system is accumulating delay and should make that work visible and improve it.
Transparency and benefits of Increment
Increment supports empiricism: transparency comes from a Done state, inspection is enabled by demonstrable outcomes, and adaptation follows through Product Backlog changes and better decisions. Increment provides the evidence needed to steer product direction, manage risk, and decide what to do next.
Teams that consistently produce a Done Increment tend to reduce rework, improve forecasting, and increase stakeholder trust because progress is based on working results rather than reported activity. It also reduces the need for separate stabilization phases because integration and quality are built into daily work rather than postponed.
Enablers for Effective Increments
- Clear Definition of Done - Keep completion unambiguous so inspection is reliable and hidden work is surfaced early.
- Collaborative development - Reduce handoffs, share ownership of quality, and shorten feedback cycles within the Scrum Team.
- Stakeholder engagement - Anchor inspection in usable outcomes and adapt direction based on learning, not opinion.
- Release governance that supports flow - Use lightweight risk controls that keep the product releasable and avoid long queues.
- Outcome and operational signals - Use usage data, support themes, and reliability indicators to evaluate whether the Increment helped.
Common misuse and practical guardrails
Increment is often undermined by practices that hide incomplete work. Misuse usually appears as work that looks good in a demo but is not truly usable, or as “done” work that still depends on downstream steps outside the Sprint.
- Demo-only increment - A clickable demo that is not integrated, tested, or supportable creates false confidence and delays learning; verify usability against the Definition of Done before calling it part of the Increment.
- Hardening Sprint - Deferring integration, testing, or stabilization increases late risk and pushes feedback out; integrate and test continuously so releasability is maintained throughout the Sprint.
- Weak Definition of Done - Treating “done” as coding finished hides quality work and creates rework; expand the Definition of Done to include what real use requires.
- Partial integration - Late merges and big-bang integration create surprises and unstable delivery; reduce batch size and integrate frequently to keep the product coherent.
- Release treated as someone else’s problem - Handing off “releasability” to another group adds queues and breaks transparency; make releasability a shared responsibility and improve release constraints as system work.
Improving Increment delivery
Improve Increment by tightening the Definition of Done and investing in practices that sustain it, such as automation, CI/CD, and testability. Increment becomes easier when work items are small, vertical, and independently valuable.
Increment delivery also improves when the Scrum Team uses Sprint Retrospective to address root causes of unfinished work and recurring spillover. Over time, the aim is a reliable Done Increment that enables meaningful Sprint Review learning and stronger Product Backlog adaptation toward the Product Goal.
Increment is a usable, valuable step toward the Product Goal that meets the Definition of Done and makes progress transparent each Sprint for stakeholders