Article 1 of 9 in the series.

For most of my career, the bottleneck in product development has been capacity. Teams could not build fast enough. Product Owners spent their days keeping the machine fed: refining the Product Backlog, detailing items, sequencing work so the Developers never ran out of things to do. Maximize value sat at the top of the Scrum Guide as an elegant ambition, then got translated, every Sprint, into something much smaller. For many practitioners, it came down to optimizing backlog item details, maximizing team utilization, and approving the work done.

AI is about to change that, in the next five years I expect. Development and delivery are about to stop being the bottleneck. Figuring out what to build, why to build it, and how to tell whether it made a real, positive difference is about to become the bottleneck instead. For the first time in Scrum’s thirty-year history, the Product Owner may actually have the time to do the job the Scrum Guide describes. The accountabilities in the Scrum Team will not be the same in five years as they are today. More about that in future articles.

The impact of AI raises a question that was not addressed by many teams for many years: What, exactly, is value?

A Visionary Piece, Grounded in a Reality

This is a visionary piece, not a predictive one. I cannot tell you what Scrum will become. I can share how a room full of experienced Professional Scrum Trainers thinks Scrum will evolve, and why that conversation matters for your team.

This blog series is grounded in the Scrum.org PST Face-to-Face Event #137, where Professional Scrum Trainers and Scrum.org leadership spent several days debating what the future of Scrum might uphold. The full participant credit sits at the foot of this article.

The backdrop is stark. Deloitte’s 2026 State of AI in the Enterprise study reports that 66% of organizations see tangible gains from AI adoption, while only 39% can attribute any real impact to it. That is the output-to-outcome gap in a single number. As a recent Scrum.org piece puts it, the bottleneck was never code. AI is accelerating the part of the system that was never actually broken.

What This Article Will Do

Three things, briefly. I will show you why the Scrum Guide’s silence on value has become a liability. I will propose a team-owned artifact I am going to call a Definition of Value, anchored by a simple three-part test. And I will give you four concrete steps you can take in your next Sprint.

The Silence Was Deliberate, and It Was Right at the Time

The Scrum Guide leaves value undefined on purpose. Value is context-dependent, and no universal definition would fit every product, every market, every team. This was the correct choice for a document meant to travel across industries, continents, and decades. I do not want anyone reading this to mistake the argument. The silence about value was a feature at the time. Time has changed, and the feature has become technical debt instead.

Something Had to Fill the Gap, and Output Proxies Did

Velocity. Story points. Features shipped. Teams have to measure something, so they measure what is closest to hand. These are not wrong, exactly. They are simply not definitions of value. They are activity signals asked to do work they were never designed for.

Melissa Perri calls this the build trap: measuring success by outputs rather than outcomes. Josh Seiden, in Outcomes Over Output, defines an outcome as a change in human behavior that drives business results. The vocabulary has been there for years. The artifact that operationalizes it, inside a team, has not.

AI Shifts the Needle

When a Sprint lasted two weeks, a team could catch a value mistake before too much damage was done. When an AI agent can generate a working feature in the time it takes to reread a Product Backlog item, that cushion is gone. The gap between what a team can produce and what its users can absorb has collapsed.

This is where the Amsterdam discussions kept landing. The Scrum Guide needs to move from output-centric to outcome-centric. Teams need an artifact to make that shift real. Not necessarily in the Scrum Guide itself. On the wall of every team room. Make no mistake; Scrum has always supported and encouraged outcome-thinking. Yet, too many teams stay stuck in the build trap.

The Definition of Value

If you are interested in updating your way of working for the Age of AI, a Definition of Value (DoV) becomes a new core artifact. The DoV will become an AI-powered team’s core artifact that makes value concrete, tangible, and understandable for the product. It is similar to the Definition of Done in a sense. But it is not about the quality of the output you produce. It is about clarifying the outcomes that should be created. The product team co-authors it, led by the Product Owner in collaboration with key stakeholders. It lives as a document on the wall, in the wiki, at the top of the backlog. It gets revisited and improved frequently as the product and market evolve.

The purpose is simple: ensure that everything the team does generates value. If it does not, the team (or the AIs) should not spend time refining, building, deploying, or distributing the work. If the expectation, read: assumption, is that the item will create value, it should be built and put in the hands of customers and users as soon as possible, so that the potential value can be measured and proven.

DoVs will be different across products, teams, and industries. What they should share is the MSA Test:

Where does a DoV sit inside existing Scrum practice? Upstream of Evidence-Based Management. EBM measures value after the fact, through Current Value, Unrealized Value, Time-to-Market, and Ability to Innovate. A DoV defines what the team is measuring in the first place. Downstream of the product vision. Vision is directional. A DoV is operational. And alongside the Definition of Done. DoD confirms the work was built correctly. DoV confirms the work was worth building.

If you want a vocabulary to start from, Scrum.org’s Five Types of Value is a useful frame. You can also learn the art of maximizing value in this companion piece: The Art of Maximizing Value. Pick one or two types that matter most for your product. Write them into your first DoV.

What a Definition of Value Looks Like in Practice

Abstract frameworks tend to evaporate on the way back to the office. So here is what a concrete DoV might look like for a product team building new-user onboarding in a SaaS product.

<strong>Our Definition of Value.</strong> We create value when a new user reaches their first success moment, completing an end-to-end workflow, within seventy-two hours of signup, without contacting support, and returning on at least one of the next three days. We measure this through activation analytics, support ticket volume, and day-one-to-seven return rate.

Apply the MSA Test. Measurable: three data points, all queryable. Significant: activation is the leading indicator of retention, which drives revenue. Adopted: every metric measures what users actually do, not whether a feature exists. The DoV passes. A team can now walk into refinement and ask, for every Product Backlog item: does this item, if built, move that definition? If yes, it belongs in the Sprint. If no, or if nobody can tell, it goes back for sharpening.

Now picture the same team without a DoV. They ship a redesigned onboarding flow in two Sprints. The Definition of Done is met. The release lands cleanly. Three weeks later, only 18% of new users have touched the new flow, because it requires a settings toggle nobody prompts them to flip. Every Sprint commitment was hit. No value was delivered. With the DoV above, the Product Backlog item would not have survived refinement; the toggle dependency would have killed the seventy-two-hour metric before a line of code was written.

That is the difference an agreed-upon Definition of Value might make.

Four Things You Can Do in Your Next Sprint

A fifth step, if you already use EBM: map every DoV statement to at least one Key Value Area. The two artifacts get stronger together.

The Turn

The Scrum Guide’s silence on value was survivable when delivery was the bottleneck. The workaround, output proxies, was good enough to ship software without embarrassment. AI is removing that cushion. For the Product Owner, this is not a threat. It is the first real chance, in thirty years, to do the work the Scrum Guide asks for. Maximize value. Not maximize backlog item details. Not maximize team utilization. Actual, proven, adopted value.

A Definition of Value is how you make that concrete on your team, this Sprint, without waiting for anyone to rewrite the Guide.

Over to You

I am curious what a Definition of Value looks like on your team. What counts as value on the product you work on today? Could you answer that in one sentence? If you can, I would like to read it. If you cannot, that is worth a conversation with your team this week.

The next article in the series asks a harder question. As AI agents take on more of the work, who stays accountable for the outcome? 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.

Sources

The Bottleneck Was Never Code, Scrum.org

Evidence-Based Management, Scrum.org

Five Types of Value, Scrum.org

The Art of Maximizing Value, Robbin Schuurman (Medium)

Escaping the Build Trap, Melissa Perri (summary)

Outcomes Over Output, Josh Seiden

The State of AI in the Enterprise 2026, Deloitte