The Product Increment is the cumulative sum of all Product Backlog Items completed in the current Sprint and all previous Sprints. It is defined by one critical constraint: work cannot be considered part of an Increment unless it fully meets the team's Definition of Done. If it is not done, it is not in the Increment — regardless of how close to finished it might be.

This constraint is not administrative pedantry. It is the mechanism that keeps the Increment honest. An Increment composed of "almost done" work is not a potentially shippable product — it is a collection of technical debt.

What the Increment is for

The Product Increment serves two purposes that are worth distinguishing.

The first is enabling customer and stakeholder feedback. By delivering working functionality regularly, the team creates opportunities for real users to interact with the product and for stakeholders to see whether what is being built matches what they needed. This feedback loop — short by design — is what allows teams to detect misalignment early rather than at the end of a long development cycle, when correction is expensive.

The second is providing a concrete, honest measure of progress. The Agile Manifesto is explicit: working software is the primary measure of progress. The Increment embodies this principle. A team that can point to a working, usable Increment at the end of every Sprint is demonstrating progress in the only way that actually counts.

Potentially shippable vs potentially releasable

An important and frequently blurred distinction: at the end of each Sprint, the Increment should be "potentially shippable" — technically complete, meeting the Definition of Done, and in a usable state. This does not mean it should necessarily be released.

"Potentially releasable" is a higher bar that incorporates business and strategic considerations beyond technical completeness. Release timing may depend on marketing campaigns, regulatory approval, accumulated feature sets, or competitive positioning. Multiple Sprints of potentially shippable Increments may be accumulated before any release decision is made.

The Scrum Team is responsible for the first bar — always delivering a potentially shippable Increment. The decision about when to release is a business decision, made by the Product Owner in consultation with stakeholders.

Who is responsible

The Developers are accountable for delivering the Increment — for ensuring that the work completed each Sprint meets the Definition of Done and constitutes a genuine step forward in the product's development.

The Product Owner is accountable for ensuring that the Increment is valuable — that the backlog items the team is completing align with strategic goals and customer needs.

The Scrum Master is accountable for ensuring the process that produces the Increment is sound — that events happen effectively, that impediments are removed, and that the team understands and applies Scrum as intended.

All three accountabilities are necessary. An Increment that is technically complete but misaligned with value is a failure of the Product Owner accountability. An Increment that is well-directed but half-finished is a failure of the Developers' accountability. An Increment produced through a dysfunctional process is a failure of the Scrum Master's accountability.

The Definition of Done

The Definition of Done is the shared agreement about what "complete" means for work in the team's context. It typically covers technical quality standards (code reviewed, tests written and passing, documentation updated), integration requirements (merged to main branch, deployable to staging), and any domain-specific requirements (security review completed, accessibility checked).

A weak Definition of Done produces Increments that are nominally complete but actually fragile. A clear, demanding Definition of Done produces Increments that are genuinely ready for use and for continued development. The Definition of Done is one of the most consequential agreements a Scrum Team makes, and it is worth investing time in getting it right — and in revisiting it as the team's understanding of their standards develops.