What is an increment in Scrum?

Most Scrum teams know they’re supposed to deliver something at the end of every Sprint. Fewer can say with confidence what that something actually is (or whether what they’re delivering qualifies). That gap is where the increment comes in.

An increment in Scrum is a usable, verified step toward the product goal. It builds on every increment that came before it, and it only counts if it meets the team’s definition of done (DoD).

The increment is one of Scrum's three official artifacts, which means Scrum treats it with the same structural weight as the product backlog and the sprint backlog.

This post explains what an increment is, what makes it usable, how it relates to the definition of done, who is accountable for it, and how it differs from related concepts such as releases, deliverables, and product backlog items.

What is an increment in Scrum?

Before diving into why it matters and how it works, it helps to get precise on what the increment actually is because it is easy to confuse it with adjacent terms. An increment is the sum of all completed product backlog Items from the current sprint, combined with all previous increments.

It represents the latest usable version of the product at any given moment, not a snapshot of what is in progress, but what is done. Each increment is a concrete, additive step toward the product goal, and it must integrate cleanly with everything the team has built before.

The official Scrum Guide definition states:

It is ready right now. Whether the organization chooses to release it is a separate decision, but the increment itself is releasable.

Why does the increment in Scrum matter?

Without the increment, Scrum teams can look productive for weeks while producing nothing that works. The increment is the mechanism that prevents the hiding of fake progress.

• It creates transparency about real progress. Stakeholders see the working product because they want to know what has been done and is verifiable.
• It forces the team to focus on outcomes over activity. Hours logged and tasks moved do not equal value. The increment keeps the team anchored to what is finished and functional.
• It supports meaningful inspection at the sprint review. The sprint review only works if there is something real to react to. The increment gives stakeholders a concrete basis for feedback.
• It eliminates the slow creep of unfinished work. Partially completed features that are treated as done are among the most common failures in product development. The increment’s standards shut that down.

How does the increment in Scrum relate to the definition of done?

If the increment is what the team produces, the definition of done is the standard that determines whether it qualifies. These two things are permanently connected.

In Scrum, every artifact has a commitment: the product backlog holds the product goal, the sprint backlog holds the sprint goal, and the increment holds the definition of done. You cannot separate the increment from its definition of done any more than you can separate a contract from its terms.

Here is what that relationship means in practice:

• Work is not part of the increment unless it meets the definition of done. There is no partial credit. A feature that is 90% complete at the end of a sprint either gets finished within the sprint or returns to the product backlog. It does not cross into the increment with an asterisk attached.
• Partially completed work does not produce a usable increment. If the team cannot confidently say a piece of work meets the standards they agreed to, it is not part of the increment. 
• The DoD creates shared quality expectations across the team. Before a Sprint begins, everyone (developers, product owner, Scrum master) understands what “done” requires. This prevents end-of-sprint surprises and maintains consistent quality across Sprints.
• Without the DoD, “done” becomes whatever anyone says it is. That is the version that erodes trust and confuses stakeholders.

Does every sprint need an increment?

Short answer: yes, every time.

The Scrum Guide is explicit. Developers are committed to creating a usable increment every sprint. This is not a guideline for mature teams or a best practice for when things go smoothly. It is a commitment that applies regardless of the sprint length, team size, or the complexity of the work.

What trips teams up is conflating the increment with a release. Producing an increment does not mean shipping to end users. The team’s job is to produce something that could be released by the end of every sprint.

When a team consistently fails to produce a usable increment, it usually points to sprint goals that were scoped too large, a DoD that nobody fully understood, or backlog items that entered the sprint without enough refinement. Each of those is fixable, but only if the team is honest about what actually happened.

Example of an increment in Scrum

Abstract definitions are easier to understand with a concrete case. Here is what an increment looks like across three sprints. Imagine a team building an internal expense reporting tool. The increment grows like this:

• Sprint 1: A working login screen with authentication. It needs to be functional and tested to meet the definition of done.
• Sprint 2: A functional expense submission form that saves to the database. It needs to be integrated with the login from Sprint 1.
• Sprint 3: A manager approval workflow that routes submitted expenses for review. It needs to be connected to both prior components.

By Sprint 3, the increment is all three of these layers working together. A manager can log in, view submitted expenses, and approve or reject them. That is a usable increment. Notification emails, reporting dashboards, and export features may still be on the backlog, and that is fine, but the increment does not need to be the whole product. It needs to be a working, “done” slice.

What would not count: a half-built approval screen that does not connect to the database, or a workflow that technically functions but breaks the Sprint 1 login when run together. Either of those fails the increment standard because they do not meet the DoD requirements and do not work with prior increments.

Who is responsible for the increment in Scrum?

This is a question teams coming from traditional project management often get wrong because in waterfall environments, one person typically owns the deliverable, but in Scrum, accountability works differently.

The entire Scrum team is accountable for producing a valuable, usable increment every Sprint. That includes the product owner, the Scrum master, and the developers. 

• The entire Scrum team is accountable for the increment’s existence and quality. The product owner shapes what goes into it through backlog management. The Scrum master creates the conditions for the team to work effectively, and the developers build.
• Developers are committed to delivering a usable increment in each sprint. They are the ones applying the DoD, building the work, and deciding whether something is finished.

The shared accountability is a deliberate feature. When one person owns the deliverable, everyone else can distance themselves from quality. When the whole team owns the increment, quality becomes everyone’s problem in the best sense. No one gets to hand something off and say it is someone else’s standard to uphold.

How does the increment support the sprint review?

The sprint review is where the increment gets inspected with stakeholders. The team shows what was built, stakeholders engage with it, and that exchange shapes what gets prioritized next on the product backlog. 

Increment vs product backlog item

People sometimes use these terms interchangeably, but they describe different things at different stages of the work. A product backlog item (PBI) is a unit of planned work that lives in the backlog and can be in any state, from a rough idea to something fully refined and ready to pull into a sprint. The increment, on the other hand, is what results when that work is completed, verified, and integrated. 

A PBI is the input; the increment is the output.

Increment vs release

One of the most common misconceptions in Scrum is that producing an increment means releasing to users. It does not, and conflating the two causes teams to either over-release (shipping half-baked work) or under-increment (skipping the done standard because they are not planning to release anyway).

The increment and the release are two separate decisions. The increment is a technical and quality commitment the team makes every Sprint, and the release is a business decision about when to put that increment in front of users.

Increment vs deliverable

Deliverables come from traditional project management and typically mean something handed off at a milestone, reviewed against a spec, and closed out. 

The most important difference is that a deliverable is usually standalone, produced once at a defined point. The increment is cumulative because every sprint’s increment must work with all prior increments.

How Wrike helps Scrum teams

When teams understand what makes an increment valid, apply their definition of done without exception, and show up to sprint reviews with a working product, everything else in Scrum gets sharper.

For teams looking to tighten their planning, tracking, and delivery of increments, having the right tools makes a real difference. Wrike helps Scrum teams manage their backlogs, track sprint progress, and maintain clear accountability, so nothing slips through the cracks between “in progress” and “done.”