product-increment-in-scum

An Increment is everything the team has completed that meets the Definition of Done, added to everything completed before it. Two things people usually get wrong: a Sprint can produce several Increments rather than one, and an Increment can be released to stakeholders before the Sprint ends. The Sprint Review is not a release gate.

Key Highlights

• The Scrum Guide calls it the Increment. Product Increment is common usage and means the same thing.
• The Definition of Done is the commitment attached to the Increment. Work that does not meet it is not part of the Increment.
• Multiple Increments may be created within a single Sprint. One Sprint does not mean one Increment.
• An Increment may be delivered to stakeholders before the Sprint ends, and the Sprint Review should not hold up a release.
• Each Increment is additive to all prior ones and thoroughly verified, so they work together rather than accumulating separately.
• Usable is the test. Something built but not usable is not an Increment.

What the Increment Actually Is

The Increment is one of the three Scrum artefacts, alongside the Product Backlog and the Sprint Backlog. It is the concrete one: the working output rather than a list of intentions.

Specifically, it is the sum of all Product Backlog items completed during a Sprint plus every Increment before it, integrated and verified so that everything works together. It is a stepping stone toward the Product Goal, and its purpose is to give transparent evidence of progress that cannot be faked.

A note on the name. The Scrum Guide consistently says Increment rather than Product Increment. Both terms are in wide use and refer to the same artefact, so nothing turns on which you say. If you are sitting an exam, the Guide's term is the safer one.

The full set of artefacts and their commitments is covered in our guide to the three artefacts of Scrum.

If you are working through the framework and want to check where you stand, our free CSM practice test takes a few minutes.

The Definition of Done Is the Test

Every artefact in Scrum has a commitment attached to it, and the Increment's is the Definition of Done.

That relationship is stricter than people assume. Work cannot be considered part of an Increment unless it meets the Definition of Done. Not mostly meets it. Not meets it apart from the tests. An item that falls short is not part of the Increment, is not presented at the Sprint Review, and returns to the Product Backlog.

This is what gives the Increment its meaning. If items could be included while incomplete, the artefact would describe intentions rather than working software, and nobody could rely on it. The Definition of Done is the mechanism that keeps it honest, and who owns that standard is covered in our guide to who creates the Definition of Done.

The practical consequence for a team is that the Definition of Done should be genuinely achievable within a Sprint. A standard nobody can meet produces Sprints with no Increment at all, which is worse than a modest standard consistently met.

A Sprint Can Produce Several Increments

The first correction, and it contradicts what most articles imply.

The Scrum Guide states plainly that multiple Increments may be created within a Sprint. There is no rule that a Sprint produces exactly one.

In practice this is what a team with good engineering practice actually does. Each item that meets the Definition of Done and is integrated becomes part of the Increment as it completes. By day four the team may have produced three Increments; by the end of the Sprint, several more.

Why it matters.

It removes the artificial batch. Treating the Increment as a single thing assembled at the end recreates a mini waterfall inside the Sprint, with integration and verification bunched into the final days.

It matches how continuous integration works. A team integrating daily is producing verified, working output continuously, and calling that a single end of Sprint event describes it inaccurately.

It changes what the Sprint Review shows. The Review inspects the Increment as it stands, which is the accumulation of everything completed, not a package prepared for the occasion.

The single Increment per Sprint idea is a simplification that has hardened into a belief. It is a reasonable mental model for a team new to Scrum and it is not what the framework says.

The Sprint Review Is Not a Release Gate

The second correction, and the more consequential one.

An Increment may be delivered to stakeholders before the end of the Sprint. The Scrum Guide is explicit that the Sprint Review should not be treated as a gate that releases must wait for.

That means a team can release on day three of a two week Sprint if the work is done and the Product Owner decides to. Nothing in Scrum requires holding completed, verified, usable work until a meeting happens.

Where the misconception comes from is understandable. The Sprint Review is when stakeholders see the Increment, so it feels like the release point. But the Review is an inspect and adapt event about what to build next, not an approval step for what has already been built.

Two practical consequences.

Release cadence and Sprint cadence are separate decisions. A team on two week Sprints can release daily, weekly, or once a quarter. The Sprint is a container for inspection and adaptation, not a shipping schedule.

Holding finished work costs something. Value delivered later is value delayed, and a team sitting on completed functionality for eight days because the Review is on Thursday is choosing a delay with no benefit attached.

The decision to release is the Product Owner's. What Scrum provides is the guarantee that the Increment is in a releasable state, which our guide to the Sprint Review meeting covers in the context of the event itself.

Additive and Verified

Two words in the definition doing a lot of work.

Additive. Each Increment builds on all prior Increments. It is not a separate deliverable sitting alongside the last one; it is the whole thing, updated. This is why the Increment is described as cumulative rather than as the output of one Sprint.

Thoroughly verified. Increments must work together. Something that functions in isolation and breaks the previous Increment has not met the bar, regardless of whether its own acceptance criteria pass.

The practical implication is that regression matters as much as new functionality. A team producing new work each Sprint while quietly breaking earlier work is not producing Increments; it is producing changes. That distinction is why automated testing tends to become necessary rather than optional once a product reaches any size, and where the accountability for it sits is covered in our guide to who is responsible for quality in a Scrum team.

A Worked Example

Concrete helps, since the cumulative nature of the artefact is the part people find abstract.

A team is building a customer portal on two week Sprints.

Sprint one. They complete sign in and password reset. Both meet the Definition of Done and are integrated. The Increment is: a portal where a customer can sign in and reset a password. It is usable. It could be released.

Sprint two. They complete order history and a profile page. The Increment is now sign in, password reset, order history and profile. Not two separate deliverables, one thing containing all four.

Sprint three. They complete a downloadable invoice feature, and in doing so break password reset. Password reset now fails for a subset of users.

That third Sprint is the instructive one. The team completed the invoice work and met its acceptance criteria. They have not produced a valid Increment, because Increments must be thoroughly verified and work together, and this one broke prior functionality. The honest position is that the Increment is not in a releasable state until the regression is fixed.

Teams frequently handle this by shipping anyway and logging a defect. That is a decision the Product Owner can make, and it should be made knowingly rather than by quietly redefining what done means. The alternative, fixing it before calling the Sprint complete, is what the artefact actually asks for.

Sprint four. They fix the regression and complete two more items. The Increment is now everything from Sprints one to four, verified together. Note that the fix produced no new functionality and was still necessary, which is why regression work belongs in the Sprint rather than in a backlog of things to get to eventually.

What Is Not an Increment

Clearer by exclusion, and each of these is common.

Work that is finished but not integrated. Sitting on a branch is not part of the Increment, however complete it looks to the person who wrote it.

Work that meets acceptance criteria but not the Definition of Done. The item is complete; the Increment standard is not met.

A prototype or a demonstration build. Useful, and not usable in the sense the artefact requires.

Documentation or designs alone. They may support an Increment and are not one, since the Increment is working output. This catches teams whose Sprint produced a specification, a set of wireframes or an architecture decision and who present it at the Review as the Sprint's outcome. Those are legitimate work and none of them is usable in the sense the artefact requires.

Anything the team would be uncomfortable releasing. The test is usable. If the honest answer to could this go live is no, it is not part of the Increment yet.

Work sitting behind a feature flag that has never been tested on. Turning something off does not make it verified. If it would break when enabled, it has not met the standard, and shipping it disabled is deferring the problem rather than solving it.

A Sprint's output presented with caveats. Nearly done, needs a bit of testing, works apart from the edge cases. All of these describe something outside the Increment being shown as though it were inside it, which quietly destroys the artefact's meaning.

That last one is the most damaging because it is the most socially comfortable. Showing incomplete work at a Sprint Review feels like transparency and functions as the opposite, since stakeholders lose the ability to judge what is genuinely finished.

The Three Artefacts and Their Commitments

Useful context, since the Increment only makes sense alongside the other two.

The pattern is that each artefact carries a commitment giving it purpose and making progress measurable. Without the Definition of Done, the Increment is just whatever the team says it finished.

Detail on the other two is in our guides to the Product Backlog and the Sprint Backlog, and how the Sprint Goal shapes the work is covered separately.

Why Usable Is the Hard Word

Of everything in the definition, usable causes the most difficulty, and it is worth separating from released.

Usable means someone could use it. The functionality works, it is integrated, it has been verified, and nothing about its state prevents it going to a real user. It does not mean anyone has decided to send it to them.

Released means it has gone. A separate decision, made by the Product Owner, often for reasons unrelated to readiness: a marketing date, a customer commitment, a training schedule.

The distinction matters because teams conflate them in both directions. Some treat unreleased work as unfinished, which means the Increment never feels complete. Others treat released as the standard, which produces pressure to ship things that are not ready in order to claim progress.

The test that works is a question: if the Product Owner asked for this to go live this afternoon, could it, without anyone doing further work? If yes, it is part of the Increment. If the honest answer involves finishing tests, cleaning something up, or checking one more thing, it is not there yet.

That test also exposes a pattern worth watching. A team where the answer is routinely almost has a Definition of Done describing an aspiration rather than a practice, and the gap tends to widen quietly until a release goes badly. Where the events fit around all of this is covered in our guide to the five events of Scrum.

Common Misconceptions

One Sprint produces one Increment. Multiple Increments may be created within a Sprint.

The Increment is released at the Sprint Review. It may be released whenever the Product Owner chooses, including before the Sprint ends.

The Increment is only this Sprint's work. It is cumulative, comprising everything completed to date.

An Increment must be released. It must be usable and releasable. Whether to release is a separate decision.

Partially complete work counts if most of it is done. It does not. The Definition of Done is binary.

The Increment is a demo. A demonstration is a presentation of the Increment. The artefact is the working output itself, and it exists whether or not anyone shows it to anybody.

Only the Developers care about it. The Increment is the clearest signal stakeholders have about genuine progress, since it either works or it does not. Percentage complete figures and burndown charts can both look healthy while nothing usable exists.

Every Sprint must produce an Increment. A Sprint where nothing met the Definition of Done produces no Increment. That is a bad outcome and it is possible, and pretending otherwise by relaxing the standard is worse. Recognising which is happening is part of what CSM Certification Training prepares a Scrum Master to spot.

Closing Thoughts

The Increment is the artefact that keeps Scrum honest. Backlogs describe intentions and a Sprint Goal describes an aim, and the Increment is the only one that either exists or does not.

The two corrections worth carrying away are the ones most teams have absorbed backwards. A Sprint can produce several Increments, not one, and treating it as a single package assembled at the end recreates the batching that short cycles exist to remove. And the Sprint Review is not a release gate, so completed work does not need to wait for a meeting before it reaches the people who asked for it.

Underneath both sits the Definition of Done, which is what makes the artefact mean anything. A team that relaxes it to avoid an uncomfortable Sprint Review has not solved a delivery problem; it has removed the only reliable signal it had.

If you are the person holding that line, CSM Certification Training covers the artefacts, their commitments and the practical facilitation that keeps standards from quietly eroding under pressure. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to check your grounding first.