Skip to main content
New: 9 PM Courses with hands-on exercises and certificates
Back to Glossary
DeliveryI

Increment

Definition

An increment in Scrum is the sum of all product backlog items completed during a sprint, combined with the increments of all previous sprints. Each increment is a step toward the product vision. It must be in a usable condition and meet the team's Definition of Done, regardless of whether the Product Owner decides to release it.

The increment is one of Scrum's three artifacts (alongside the Product Backlog and Sprint Backlog). It represents the tangible output of the team's work. The concept enforces a discipline: every sprint must produce something that works. Not a design document. Not a prototype that only runs on one developer's machine. A working, integrated product that could be put in front of users.

This discipline prevents the common antipattern of "90% done" features that drag across multiple sprints without ever reaching a shippable state. By requiring a done increment every sprint, Scrum forces teams to break work into small, completable chunks rather than attempting large features that take months to finish.

Why It Matters for Product Managers

The increment is what you demo at the sprint review. It is the concrete evidence that the team's sprint was productive. For PMs, thinking in increments means thinking about value delivery in small, frequent batches rather than big-bang releases.

This has direct implications for how you write user stories and structure your roadmap. Each story should deliver a slice of user value that contributes to a working increment. The MVP concept is essentially the minimum set of increments needed to validate a product hypothesis. If your stories are structured so that the product is broken until all of them are done, you are not building incrementally.

How to Apply It

  • Ensure every sprint produces at least one demonstrable increment
  • Structure user stories as vertical slices of functionality, not horizontal layers
  • Use feature flags to merge increments to production without exposing unfinished features
  • Demo the increment at every sprint review, even if it is small
  • Track how often increments are actually released (release frequency is a useful health metric)
  • If an increment cannot be demonstrated, investigate why the Definition of Done was not met

The guide on building a product roadmap covers how to plan releases as a sequence of increments, each delivering measurable user value.

Frequently Asked Questions

What qualifies as a Scrum increment?+
An increment must meet three criteria. First, it must be a working piece of the product, not just code checked into a branch. Second, it must meet the team's Definition of Done (tested, integrated, documented as required). Third, it must be additive to all previous increments, meaning the product as a whole is in a usable, potentially releasable state. A half-built feature that cannot be demonstrated or used does not count as an increment, even if significant effort went into it. The increment is about delivered value, not effort expended.
Does the increment have to be released to users every sprint?+
No. 'Potentially releasable' does not mean 'must be released.' The increment must be in a state where it could be released if the Product Owner decides to. Many teams accumulate several increments and release them together at a planned date. The key is that the decision to release is a business decision, not a technical one. If the increment is not releasable because of bugs, missing tests, or integration issues, then it does not meet the Definition of Done. Feature flags allow teams to merge increments into production without exposing them to users.
Can there be multiple increments within a single sprint?+
Yes. The Scrum Guide (2020 revision) clarifies that an increment can be delivered at any point during the sprint, not only at the end. A team might deliver three increments during a two-week sprint: one on day 3, one on day 7, and one on day 10. This aligns with continuous delivery practices where code is shipped multiple times per day. The sprint review then inspects all increments delivered during the sprint period. The sprint boundary is a planning and inspection cadence, not a delivery gate.

Explore More PM Terms

Browse our complete glossary of 100+ product management terms.