What is an Increment in Scrum?
Increment in Scrum
In Scrum, the Increment is the sum of every completed backlog item from the current sprint, added to everything completed in every sprint before it.
An Increment is one of the three formal artifacts in Scrum, alongside the Product Backlog and the Sprint Backlog. It's the sum of every backlog item the team has finished, this sprint and every sprint before it, combined into one cumulative, usable piece of product. A single Increment can include work finished in sprint one, sprint four, and sprint nine, all at once, not only what shipped this cycle.
The word cumulative is what separates an Increment from a finished task. Completing one task, even a large one, produces a done item on a board. An Increment is the running total: everything that's ever been finished, integrated together, in a state a stakeholder could inspect or a team could ship if the decision were made to release right now. A sprint that produces three finished stories adds three items to the Increment; it doesn't create a new, separate Increment from scratch.
An item only joins the Increment once it meets the team's Definition of Done, and the Increment as a whole is what gets inspected at the sprint review. This entry focuses on what the Increment specifically is and how it accumulates; for what 'done' means for each item, see Definition of Done, and for the meeting where the Increment gets inspected, see sprint review.
Why 'Cumulative' Is the Key Word
The Scrum Guide describes the Increment as a concrete stepping stone toward a product goal, and treats each new piece of finished work as additive to everything already delivered. In practice, this means a team doesn't reset to zero each sprint. Sprint five's Increment includes sprint five's new work sitting on top of sprints one through four, not a fresh pile of output measured on its own.
Increment vs a Single Completed Task
A finished task and the Increment look related, but they operate at different scopes.
| A completed task | The Increment | |
|---|---|---|
| Scope | One item, done in isolation | Every item ever completed, combined |
| Meets Definition of Done | Should, for that item | Every piece inside it should |
| Changes over time | No, it's finished once | Grows every sprint that adds anything |
| Inspected at | Wherever the team reviews individual work | Sprint review, as a whole |
What an Increment Requires
Not every pile of finished tasks qualifies as a usable Increment. A few conditions have to hold:
- Every item inside it meets the team's Definition of Done, not a partial or informal version of it
- The whole is usable, in a state that could be released or inspected even if the decision is made not to ship yet
- New work is integrated with everything built before it, not a standalone demo disconnected from the rest of the product
- It's inspected as one whole at the sprint review, not item by item across separate conversations
A Worked Example: Increment Across Four Sprints
A 6-person team tracks how the Increment accumulates across its first four sprints:
| Sprint | New items completed | Increment after this sprint |
|---|---|---|
| Sprint 1 | 3 items | 3 completed, 3 usable |
| Sprint 2 | 4 items | 7 completed, 7 usable |
| Sprint 3 | 2 items; 1 earlier item reopened (defect found) | 9 completed, 8 usable |
| Sprint 4 | 5 items; reopened item fixed and rejoins | 14 completed, 14 usable |
When Finished Work Doesn't Join the Increment
A few situations keep work out of the cumulative total, or pull it back out after the fact:
- An item doesn't meet the Definition of Done: it stays out until it does
- An item depends on something not yet integrated: it's blocked, not counted
- A regression surfaces in already-included work: that piece is temporarily removed from the usable Increment until it's fixed
Tracking Cumulative Progress in Melororium
Project views in Melororium track cumulative completed tasks against total project scope, not only what closed this week, so a team can watch the running total of finished, reviewed work build sprint over sprint instead of seeing only this cycle's output in isolation.
In Melororium
See cumulative project progress in Melororium
Common mistakes with increment in scrum
What teams get wrong most often, and what to do instead.
- 1
Reporting each sprint's output as its own separate deliverable
Showing only 'what shipped this sprint' at a review and never placing it against everything already built, losing the sense of cumulative progress the Increment is meant to represent.
- 2
Counting unfinished or unreviewed work in the total
Inflating the Increment with items that haven't fully met the Definition of Done, so the cumulative number overstates how much is genuinely usable.
- 3
Not tracking regressions back out of the Increment
A bug turns up in already-done work, but the team keeps counting that piece as finished instead of pulling it back out of the usable total until it's fixed.
- 4
Demoing the Increment as disconnected pieces
Showing a sprint's new items in isolation at the review instead of in the context of the whole product, so stakeholders lose track of what's accumulated.
Frequently asked questions
Is the Increment the same as a release?
No. A release is a business decision to ship. The Increment is the current state of everything usable. A team can sit on a fully usable Increment for months without releasing it.
Does every sprint produce a new Increment?
Every sprint adds to the same ongoing Increment rather than starting a fresh one. The Scrum Guide treats it as one running artifact that grows over the life of the product.
What happens to the Increment if a sprint produces nothing that meets the Definition of Done?
It doesn't grow that sprint. It stays at its previous size rather than resetting or shrinking, unless something already inside it breaks.
Do non-Scrum teams have an equivalent to the Increment?
Informally, yes. Any team accumulating finished work cycle over cycle is building something like an Increment. The term itself, and its tie to a formal Definition of Done, belongs specifically to Scrum.
How does Melororium track something like an Increment?
Project views show cumulative completed tasks against total scope, so a team can see the running total of finished, reviewed work grow across sprints instead of only seeing what closed in the current cycle.
