From Usable Increment to Used and Adopted Solution

Article 4 of 9 in the series.

Picture a team with a streak any Scrum Master would be proud of. Twelve Sprints in a row, every Sprint commitment met. Every Increment passes the Definition of Done. Every release deploys cleanly. Every retrospective closes with green lights on the board.

Product adoption is flat for a quarter.

The Increment is usable. The code runs. The features work. The Definition of Done bar is cleared, every time. On the only test that matters for a product team, whether real users are actually using and adopting the thing, the Increment quietly fails. Twelve Sprints of motion, zero Sprints of behavior change. Usable, yes. Used and adopted, no.

In the first article of this series, I proposed a Definition of Value. In the second, I argued that accountability concentrates as agents enter the team. In the third, I reframed refinement as an option-framing exercise. This article asks a harder question: when AI is in the room, what actually counts as an Increment, and what is the journey from a usable Increment to a used and adopted solution?

This is a visionary piece, not a predictive one. I cannot tell you how the Scrum Guide will or should evolve its definition of Increment. I can share how a room full of experienced Professional Scrum Trainers thinks about it, and why your team needs a stricter bar this Sprint than the Guide currently asks for. The full list of contributors from the Amsterdam Face-to-Face Event sits at the foot of the article. The arguments here are mine. The thinking is ours.

The Scrum Guide Chose Usable for a Reason

The Scrum Guide defines the Increment as "a concrete stepping stone toward the Product Goal." It must be usable. It must be additive. It must be verified. That was, in 2020, a serious, demanding, and correct bar. Many teams did not reliably clear it. Teams shipping half-built features, broken builds, and partial feature flags were common. The word usable was a disciplined word.

Make no mistake; the Scrum Guide was right at the time. The bar it set was the right bar for the bottleneck the industry was fighting. Usable-and-verified separated professional teams from the rest.

AI Shifts the Threshold Again

The bottleneck has moved. AI agents can now produce working, deployable, usable code at a pace most teams have never experienced. "Usable" is still a meaningful word. It is no longer a meaningfully hard one. When Increments arrive faster than users can absorb them, shipping usable software stops distinguishing teams that create value from teams that create motion.

The next threshold is already visible, and the Amsterdam room kept circling it: an Increment is only real when it is used and adopted.

Deloitte's 2026 State of AI in the Enterprise study shows 66% of organizations reporting tangible gains from AI adoption, and only 39% able to attribute any real impact to it. That is the same output-to-outcome gap I opened the series with. It is, at the Increment level, the usable-but-unused gap.

The Adoption Increment

I want to propose a sharper definition, usable alongside the Scrum Guide rather than replacing it. Call it an Adoption Increment.

An Adoption Increment is an Increment that (1) meets the Definition of Done, and (2) has been used by a named user, for its intended purpose, and (3) produced observable, measurable, adoption evidence inside a defined feedback window.

Three clauses. All three required. The Definition of Done verifies that the work was built correctly. Adoption verifies that the work was worth building. Both are needed. Neither is sufficient alone.

If that language sounds familiar, it should. It is the Adopted row of the MSA Test from the first article in this series, made concrete at the Increment level. The Definition of Value sets what counts. The Adoption Increment sets when it counts.

Where This Lives Inside Scrum

The Adoption Increment extends the Definition of Done. It does not replace it. The Product Owner is accountable for whether a given Increment cleared the adoption bar. The Developers are accountable for instrumenting the Increment to make adoption observable. The Scrum Master is accountable for protecting the discipline, so that "shipped" does not quietly become shorthand for "done."

In practice, an Adoption Increment means three mechanics join the team's working agreement.

Pilot cohorts and feature flags. Every non-trivial Increment ships behind a flag, to a named cohort. Real users in a real cohort, not synthetic traffic.

Adoption instrumentation, shipped with the feature. Whatever the team said at refinement would count as evidence, in the Option Frame from Article 3, is live by the first day of release. Agents are excellent at scaffolding this instrumentation. Humans are accountable for deciding whether the evidence cleared the bar.

An adoption window, time-boxed. Seven days is a reasonable starting point. Before the window closes, the Increment is a bet under test. After it closes, the team reads the evidence and decides: adopted, not adopted, or inconclusive. If not adopted, the item goes back into refinement. The bet was wrong, or the frame was wrong. Either is useful.

What This Looks Like in Practice

Return to the SaaS onboarding team from the first article. They ship a redesigned onboarding flow, meeting Definition of Done. The old story ended there, with the team proud of the release. The new story, under an Adoption Increment discipline, keeps running for seven more days.

Day three: only 11% of new users have touched the new flow. The feature requires a settings toggle no one is being prompted to flip. Day five: support tickets about onboarding have ticked up slightly. Day seven: adoption sits at 18%. The target, set in refinement, was 60%.

Under an Adoption Increment rule, the Increment is not complete. The flag stays on for the cohort. The item goes back to refinement. The team writes a new Bet in the Option Frame: "we believe removing the settings toggle and auto-prompting the new flow will move adoption past 60%." The Developers are not demoralized. They are exactly where they should be, which is inside the learning loop the Scrum Guide always wanted them in, except now with evidence that matches the claim.

Compare this to twelve Sprints of "shipped, met DoD, moved on." The same amount of code. Wildly different product outcomes.

Four Things You Can Do in Your Next Sprint

Add an "adopted" clause to your Definition of Done. Short, specific, measurable. Something like: "An Increment is Done when it meets the usability and quality bar, and when a named cohort has used it for its intended purpose within seven days." Edit to taste.

Ship every Product Backlog item with adoption instrumentation wired in. If the evidence cannot be measured on day one of release, the Option Frame row on Evidence was not real. Fix the refinement, not the dashboard.

Set a seven-day adoption window. Before that window closes, the Increment is a bet. After it closes, the team reads the evidence and declares adopted, not adopted, or inconclusive. Not-adopted items return to refinement.

In your retrospective, surface the Increments that passed DoD and failed adoption. Those are the highest-learning items of the Sprint. A team that protects these conversations gets sharper every Sprint. A team that hides them stays in the build trap, forever.

The Turn

For thirty years, Scrum has had the discipline to reject unfinished work. Developers do not ship broken builds. Teams do not accept half-baked stories into a Sprint. Quality professionals in the Scrum tradition are, rightly, allergic to the phrase good enough.

In an AI-powered world, the same community needs the same discipline for unadopted work. The Increment your team ships this Sprint is not the result. It is the hypothesis. The evidence, inside your adoption window, is the result.

Over to You

Pick the last Increment your team released. Ask two questions. Did it meet the Definition of Done? And did a real user, in a real cohort, use it for its intended purpose inside seven days? If the first answer is yes and the second is no or unknown, you have the conversation your team needs this week.

The next article goes to the Scrum event where Adoption Increments have nowhere to hide: the Sprint Review. Done honestly, the Sprint Review becomes the most consequential hour in the Sprint. Done as most teams still run it, it is a demo show with a feedback form. I want to argue for a replacement. See you there.

Contributors

This article was created based on the Scrum.org PST Face-to-Face Event #137 in Amsterdam. It would not have been possible without the discussions with: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton, and Karel Smutný. The arguments here are mine. The thinking is ours.

< Read the previous article

Sources

The Increment, Scrum.org Glossary

The Scrum Guide, Schwaber and Sutherland

The State of AI in the Enterprise 2026, Deloitte

Outcomes Over Output, Josh Seiden

Escaping the Build Trap, Melissa Perri (summary)

The Definition of Value Takes Center Stage, Article 1 of this series

Refinement Is Not Solution Design, Article 3 of this series