Increment

When products were built in one long stretch of months, nothing existed in the middle that anyone could hold. A spec appeared, then screen designs, then development started — and four months in there was still nothing you could switch on. Assembling it all in the final month surfaced every place the pieces didn't fit, at the point where no schedule was left.

Progress reports from that era had a familiar shape: login 80 percent done, checkout 60 percent done. People nodded, but nobody could check what that 80 percent was. Whether the remaining 20 percent was a day of work or three weeks was known only to the person who built it, and usually not even to them, because the hardest parts tend to sit in the last stretch rather than spread evenly across it. With a pile of half-built pieces, stopping now leaves nothing behind. Months spent, zero usable.

The increment is the rule that removes that state. It commits the team to having something switched on and usable added at the end of every cycle, which forces progress to be stated as working software instead of a percentage. Stop after any cycle and what was built up to then still has a use. That changes what a delay costs: a project cut short after three cycles hands over three cycles of working software instead of a folder of unfinished branches.

Only work that clears all three conditions belongs in the increment.

1. Items completed this cycle. Work drawn from the sprint backlog — the set of items picked at the start of the cycle — and actually finished. An item moves across only when it's done.
2. Work that meets the definition of done (DoD). The definition of done is a checklist the team writes in advance describing what earns the word finished, usually something like reviewed, tested, and ready to run in production. Different teams can hold different bars, but when people inside one team hold different bars, every cycle ends in an argument about what counted.
3. Everything the earlier cycles produced. The increment isn't just this cycle's piece; it's the whole accumulated product. If this cycle's feature broke a feature from two cycles ago, this increment isn't finished. That's why checking that the older work still runs belongs to the end of each cycle, and why teams automate that check rather than clicking through it by hand every two weeks.

What stays out makes the bar clearer. A half-built feature stays out. Work waiting on review stays out. Something coded but blocked from deployment stays out. So do mockups and design documents — they're materials for building, not something a user can use.

The bar looks strict, and loosening it costs the whole point. Start counting the thing that's 90 percent there and the end of the cycle produces "almost done" again, which is the exact state the practice was built to eliminate. The cost lands a cycle later, when the leftover ten percent turns out to be the integration nobody had tried yet.

The development team builds it. That term covers everyone who makes the product — designers and testers included, not only engineers — and it doesn't assume one person does one kind of work. This team also judges whether the result meets the definition of done.

The audience is whoever attends the sprint review, the session on the last day of the cycle where the team runs what it built and collects reactions. What gets shown there is the increment. Showing working software rather than documents or screenshots is a rule because that's what produces specific feedback. Someone looking at a mockup says it looks fine. Someone who clicked through it says they pressed save, saw nothing happen, and pressed it again. The second kind of comment is the only kind that changes what gets built next.

The people in that room are usually the ones affected by the result — sales, support, the founder. What they say becomes candidate work for the next cycle.

Usable doesn't mean shipped. The team's obligation is keeping the product releasable at any moment; when it actually goes public is a separate decision. If five features only make sense together, the increment through cycle four is complete and the release waits. Keeping those two things apart is what lets a team decide release timing on business grounds — a conference date, a customer commitment — rather than on whether the code happens to be in a shippable state that week.

"Search isn't in this cycle's increment. It hasn't met the definition of done yet."

The feature is nearly there, but it doesn't go in this result.

"Let's put the increment we're reviewing on production ahead of time."

Show the thing actually running rather than a separate demo build.

"Last cycle's increment broke with this change."

New work damaged something already in use, so this result isn't finished.

Pagedeck runs two-week cycles with the review on the final Thursday. Last cycle the team built expiry dates for document share links. The settings screen was complete, but the page a visitor sees after a link expires was still missing, so Theo pulled the item out of the increment and moved it to the next cycle. Showing half of it produces half a reaction, and a reaction to a settings screen nobody can reach through a real link is not worth the meeting.

Instead, Mia clicked through all the sharing features accumulated over the last three cycles to show what the product had become. Sofia worked through them in the order customers usually ask about, mentioned that finding the link expiry setting took her a while, and that comment went in as a candidate for the next cycle.

The most common misreading is that the increment means only what was built this cycle. The word describes something added each cycle, so picturing this cycle's piece comes naturally. But what it names is the whole accumulation to date. The distinction changes what gets verified: look only at the new piece and nobody checks at the end of the cycle whether last month's feature quietly broke.

The other frequent assumption is that the end of a cycle obligates a release. Usable sounds like shipped. In practice, staying releasable and releasing are separate decisions. Fuse them and a team either pushes out features before they're ready to be seen, or — since it can't release yet — starts waving work past the definition of done. The second case inflates numbers like velocity too, and the next cycle's plan is built on the inflated figure. A team in that loop looks faster on paper every quarter while the product a customer can actually open stays where it was.