Increment

Close

Scrum Increment

A Scrum increment is the usable product work created during a sprint.

More precisely, an increment is the completed work from the current sprint added to everything that was already done before the sprint began. Each increment builds on prior increments and should work with the product as a whole.

The increment matters because Scrum depends on learning from something real. A sprint should produce more than activity, tasks, or partially completed work. It should produce something done enough to inspect, learn from, and potentially release.

Who This Page Is For

This page is for people who want to understand the increment as a Scrum artifact.

It is especially useful for:

  • Developers who want a clearer standard for what it means to finish work in a sprint
  • Product Owners who need confidence that completed work is usable
  • Scrum Masters helping teams improve transparency and Definition of Done conversations
  • Stakeholders who want to understand what they are inspecting during a Sprint Review
  • Teams that often end sprints with work that is mostly done, almost tested, or waiting to be integrated

What This Page Covers

This page explains what a Scrum increment is, why it matters, how it relates to the Definition of Done, and how it supports inspection and adaptation.

It also explains why done is not the same as released, what makes an increment useful, and what to do when a sprint ends with unfinished work.

What Is a Scrum Increment?

A Scrum increment is the usable product created by completing work during a sprint.

If a product had ten completed features before the sprint, and the Scrum Team completes two more during the sprint, the increment includes those two new pieces added to everything already done. The product has moved forward.

That sounds simple, but it is easy for teams to blur the meaning of complete.

A product backlog item is not part of the increment because someone coded it. It is not part of the increment because a task moved to the Done column. It is not part of the increment because everyone expects testing to go fine later.

Work becomes part of the increment only when it meets the Definition of Done.

That means the work has been completed according to the quality and completion standards the Scrum Team has agreed are necessary for the product.

Why the Increment Matters

The increment is what turns Scrum from a planning rhythm into a learning rhythm.

Each sprint should create something real enough to inspect. That does not mean every sprint must end with a public release. It means the Scrum Team should create usable product work that supports feedback, learning, and better decisions.

Without a done increment, Scrum can create a false sense of progress. The Scrum Team may complete tasks, update a board, and talk through a Sprint Review while unfinished work quietly accumulates.

A usable increment helps the Scrum Team and stakeholders answer better questions:

  • Did we build what users and stakeholders actually need?
  • Is the product moving in the right direction?
  • What did we learn from seeing the work integrated?
  • What should we adapt before the next sprint?
  • Is the product in a state where the Product Owner could make a release decision?

That feedback is one of the main reasons to work in short sprints.

The Increment and the Definition of Done

The Definition of Done describes what must be true for work to be considered complete.

For one Scrum Team, that may include code review, automated tests, security checks, user documentation, integration into the main product, and verification in supported environments. For another Scrum Team, the details may be different.

Each Scrum Team’s Definition of Done will differ. What matters is that the Scrum Team shares the same honest standard for what done means.

Without a Definition of Done, the increment becomes vague. One person may think a product backlog item is done because it is coded. Another may not consider it done until it is tested, integrated, documented, and usable in the product.

A clear Definition of Done reduces that ambiguity. It helps the Scrum Team avoid hidden unfinished work and gives stakeholders more confidence in what they are inspecting.

A simple test is this:

Could the Product Owner choose to release this work, even if they decide not to?

If the answer is no because the work is unfinished, untested, unintegrated, or unusable, it is probably not part of a done increment.

Done Is Not the Same as Released

Done and released are related, but they are not the same thing.

Done means the work meets the Definition of Done and is usable. Released means the Product Owner or organization has chosen to make that work available to users or customers.

A Product Owner may decide not to release a done increment immediately. There may be business, marketing, regulatory, support, operational, or timing reasons to wait.

That is fine. Scrum does not require every sprint to end with a public release.

But Scrum does expect the Scrum Team to create a usable increment. If work cannot be released because it is unfinished, untested, unintegrated, or unusable, the problem is not release timing. The problem is that the increment is not really done.

What Makes a Good Increment?

A good increment is usable, integrated, and inspectable.

It does not need to be large. A small, finished increment is usually more useful than a large collection of partially finished work.

A good increment is:

  • Usable: It works well enough to support real feedback or a future release decision.
  • Integrated: It fits with the product as a whole, not just with one Developer’s local work.
  • Tested: It has been checked according to the Scrum Team’s quality standards.
  • Understandable: The Product Owner, stakeholders, and Scrum Team can see what changed and why it matters.
  • Aligned with the Sprint Goal: It helps the Scrum Team achieve the purpose of the sprint.
  • Done: It meets the Definition of Done.

The goal is finished, usable product work rather than progress that exists only on paper.

Examples of Scrum Increments

What counts as an increment depends on the product and the Scrum Team.

For a software product, an increment might include:

  • A new checkout option that is integrated, tested, and usable
  • A reporting improvement available behind a feature flag
  • A performance improvement that reduces page-load time
  • A bug fix that is verified and included in the product
  • A security improvement that is implemented, tested, and working in the product

For a non-software product, an increment might include:

  • A tested prototype that stakeholders can evaluate
  • A revised service process ready for a controlled pilot
  • A training module completed enough for feedback from learners
  • A policy change validated with the people who will use it
  • A new operational workflow ready to try with a small group

The common thread is not software. The common thread is usability. The Scrum Team has created something real enough to inspect and learn from.

Multiple Increments Can Be Created in a Sprint

A Scrum Team may create more than one increment during a sprint.

For example, Developers might finish a small bug fix on Tuesday, complete a reporting improvement on Thursday, and finish a checkout enhancement before the sprint ends. Each completed piece adds to the product when it meets the Definition of Done.

By the end of the sprint, the increment includes all completed work added to the product.

This is useful because the Scrum Team does not need to wait until the Sprint Review to have something done. The Sprint Review is an opportunity to inspect the outcome of the sprint with stakeholders. It should not become a gate that prevents completed work from being delivered earlier when delivery makes sense.

Increments and Sprint Reviews

The increment is usually central to the Sprint Review.

During the Sprint Review, the Scrum Team and stakeholders inspect the outcome of the sprint and discuss what to do next. The increment gives that conversation something concrete to focus on.

A Sprint Review should be more than a scripted demo. The Scrum Team should show the work that helps stakeholders understand progress, give useful feedback, or make decisions.

If the increment is not really done, the Sprint Review becomes less useful. Stakeholders may react to incomplete work. Developers may spend the meeting explaining what still needs to happen. Important feedback may be delayed until the work is fully integrated.

A done increment makes the Sprint Review more honest and more valuable.

Increment vs. Output

An increment is product progress, not simply output.

Output can include tasks completed, documents written, code committed, meetings held, or tickets moved. Those things may be necessary, but they do not always add up to usable product progress.

A sprint full of completed tasks but no usable increment should prompt a serious conversation.

The Scrum Team may need to look at:

  • Whether product backlog items are too large
  • Whether work is being split in ways that do not create usable slices
  • Whether testing and integration are happening too late
  • Whether the Definition of Done is clear enough
  • Whether Developers are starting too much work at once
  • Whether dependencies are preventing the Scrum Team from finishing

Scrum makes this visible. That visibility is useful only if the Scrum Team does something with it.

Technical Work Can Be Part of an Increment

An increment does not have to be a visible new feature.

Technical work can be part of an increment when it creates usable product progress and meets the Definition of Done.

Examples include:

  • A performance improvement that users experience as a faster product
  • A security enhancement that reduces product risk
  • A database migration that is complete and working in production-like environments
  • An architectural change that makes future work safer or faster
  • A defect fix that improves reliability

The key question is not whether the work looks like a feature. The key question is whether it is done, integrated, and useful.

Technical work becomes harder to inspect when the Scrum Team cannot explain what changed or why it matters. Developers should be prepared to explain the product impact in language the Product Owner and stakeholders can understand.

Common Problems with Scrum Increments

The Increment Is Mostly Done

“Mostly done” is not done.

Work that is coded but not tested, designed but not integrated, or reviewed but not usable creates hidden risk. It may look like progress during the sprint, but the Scrum Team still has work left before it can learn from the product.

The Increment Is Too Big

Large increments delay feedback.

When Scrum Teams try to complete too much before showing anything useful, they increase the chance that they will discover problems late. Smaller increments help Scrum Teams learn sooner and adapt with less waste.

The Increment Is Not Integrated

Separate pieces of work can look fine on their own and still fail when combined.

Integration is part of making the increment real. Developers should avoid ending the sprint with separate pieces that have not been brought together.

The Increment Cannot Be Inspected

Sometimes a Scrum Team completes work but cannot show it in a way stakeholders can understand.

That weakens feedback. The Scrum Team may need better examples, better test data, better environments, or a clearer explanation of what changed and why it matters.

The Scrum Team Confuses Tasks with Product Progress

Completing tasks is useful only if the completed tasks add up to usable product progress.

A sprint full of completed tasks but no usable increment should prompt the Scrum Team to inspect how it is splitting work, coordinating, testing, and defining done.

The Definition of Done Is Too Weak

A weak Definition of Done allows unfinished work to hide.

If the Definition of Done does not include the testing, integration, review, documentation, or other quality work needed for the product, the increment may look better than it is.

The Increment Is Saved for a Big Reveal

Stakeholders should not be surprised by the direction of the product only at the end of a long effort.

Small increments reduce the risk of building too much before learning that something should change.

Before You Call It an Increment

Before calling work part of the increment, the Scrum Team should be able to answer these questions:

  • Does the work meet the Definition of Done?
  • Is it integrated with the rest of the product?
  • Has it been tested according to the Scrum Team’s standards?
  • Is it usable enough to support feedback or a release decision?
  • Can the Product Owner and stakeholders understand what changed?
  • Does it support the Sprint Goal or Product Goal?
  • Is any unfinished work being hidden by the word done?
  • If the Product Owner chose to release it, would unfinished work be the reason not to?

Use these questions to keep the increment honest without turning the Definition of Done into bureaucracy.

FAQ

What Is an Increment in Scrum?

An increment is the usable product work completed during a sprint and added to everything already done.

Work is part of the increment only when it meets the Definition of Done.

Does Every Sprint Need an Increment?

Yes. Scrum expects each sprint to produce a usable increment.

The increment may be small. It may not be publicly released. But the sprint should create something done enough to inspect and learn from.

Is an Increment the Same as a Release?

No.

An increment is done, usable product work. A release is the decision to make that work available to users or customers.

A Scrum Team may create a done increment every sprint and release less frequently.

Can a Scrum Team Have More Than One Increment in a Sprint?

Yes.

A Scrum Team may complete multiple pieces of usable work during a sprint. Each completed piece adds to the product when it meets the Definition of Done.

Can an Increment Include Technical Work?

Yes.

Technical work can be part of an increment if it is done, integrated, useful, and meets the Definition of Done. Performance improvements, security work, architectural changes, and defect fixes can all be part of an increment.

Who Decides Whether the Increment Is Done?

The Definition of Done should make this clear.

Developers are responsible for creating work that meets the Definition of Done. The Product Owner helps clarify expectations and decides whether completed work satisfies the intended product outcome. The Scrum Master helps the Scrum Team improve when done is unclear or routinely missed.

What Happens If Work Is Not Done by the End of the Sprint?

Work that is not done should not be counted as part of the increment.

The Scrum Team and Product Owner should inspect what happened, decide what to do with the unfinished work, and use the learning to improve future planning, refinement, story splitting, or collaboration.

Does the Increment Have to Be Software?

No.

Scrum is most commonly associated with software, but an increment can be any usable product work that supports inspection and adaptation.

Is the Sprint Review a Gate for Releasing the Increment?

No.

The Sprint Review is an opportunity to inspect the outcome of the sprint and discuss what to do next. If an increment is done and it makes sense to release it before the Sprint Review, the Sprint Review should not prevent that.