Prologue to a nine-article series.

For thirty years, the defining constraint on professional product work has been delivery. Shipping reliably, at a cadence, under a Definition of Done, with working software at the end of every Sprint, was the achievement. Scrum was written to help teams reach that bar. Millions of teams, over three decades, have used it to do exactly that.

The constraint has moved.

In the last two years, AI agents have made reliable delivery something a competent team can now do without the level of discipline the 2020 Scrum Guide was written to demand. That is the good news, and it is the warning. The good news is that more teams can now clear the delivery bar than at any point in the history of software. The warning is that clearing the delivery bar no longer distinguishes the teams that create value from the teams that create motion.

If delivery is no longer the bottleneck, what is? And how does professional product work have to change, at the level of daily practice, to match?

This is a nine-article series attempting to answer that question. Not predictively. Visionarily. I cannot tell you what product development will look like in five years. I can share how a room full of experienced Professional Scrum Trainers thinks it has to evolve, and what your team can begin doing, this Sprint, to move with that shift rather than be caught by it. The full list of thought contributors sits at the foot of every article in the series.

Where This Series Comes From

In late 2025, Scrum.org hosted Professional Scrum Trainer Face-to-Face Event #137 in Amsterdam. Twenty-one of us spent several days arguing, disagreeing, revising, and sharpening each other's positions on a single question: how does Scrum, as both framework and practice, hold up in an AI-powered world?

Make no mistake; the Scrum Guide is not broken. The pillars of transparency, inspection, and adaptation are the empirical foundation on which everything in this series rests. The five values, courage, focus, commitment, respect, and openness, are not negotiable. Self-management is not something AI makes obsolete. It is something AI makes more consequential.

What is changing is not the framework. What is changing is the practice. The ceremonies that were sharp answers to the delivery bottleneck are, in many teams, becoming ceremonial answers to a bottleneck that has already moved. This series is about closing that gap.

What Each Article Argues

Nine threads, in order, building on each other.

Read in order, the nine articles build a picture of what aiming higher looks like, practice by practice, at the level of the Sprint.

What This Series Is Not

A short list, so expectations are clear from the start.

It is not a rewrite of the Scrum Guide in the age of AI (yet). To envision potential futures of product development is the target.It is not anti-AI. Agents, used well, are genuinely transformative. The series is pro-discipline, which is the opposite of anti-AI. Discipline is what separates teams that get transformative value from agents and teams that get expensive noise.

It is not a prediction of the next five years. It is a snapshot of how a serious community of practitioners is thinking, right now, about the shift already underway. Predictions age badly. Frames, if they are sharp enough, age well. It is also not a consulting pitch. The four-step closers at the foot of each article are deliberately things your team can do, in your next Sprint, without buying anything, hiring anyone, or rewriting your backlog tool.

Who This Is For

Senior Product Owners and Product Managers who want more than a polished backlog. Scrum Masters who want to protect something sharper than ceremony attendance. Developers who feel, correctly, that the shape of their job is changing faster than the job descriptions admit. Professional Scrum Trainers and coaches looking for the next set of frames to bring to their clients. Product leaders, executives, and transformation owners trying to decide what good looks like when the floor of professional delivery just dropped.

If you are scanning for tactics you can steal this Sprint, you will find them. If you are scanning for arguments you can bring to a leadership conversation this quarter, you will find those too. The series is built to work at both levels.

How to Read the Series

In order. Each article assumes the previous one. Article 2 assumes you have a Definition of Value. Article 3 assumes you are taking accountability seriously. Article 4 assumes your refinement is framing bets. Article 5 assumes you are shipping Adoption Increments. Article 6 assumes you are running Evidence Reviews. Article 7 assumes the team is ready to curate its context as a first-class artifact. Article 8 assumes that context is transparent enough to inspect. Article 9 assumes all of the above.

Read out of order, and the argument still holds, but the momentum is lost. The threads compound.

Who This Is For, Regardless of Team Shape

One note, before you read further. The arguments in this series apply whether your team is small or large, whether it is a single product development team or a collection of teams, whether you are a lone Product Owner holding one Developer and three agents, or a Chief Product Officer overseeing twelve Product Managers across four product lines. The mechanics change with scale. The principles do not. Where the practices need adjusting for a team of two or a product organization of two hundred, the articles flag it. Everywhere else, assume the practice scales up and down.

Four Things You Can Do Before You Read Article 1

The Turn

I wrote this series because I believe we are at the most consequential moment in the history of professional product work. For thirty years, the bottleneck was delivery. That era is ending. The bottleneck is becoming judgment, value, and learning. The Scrum Guide gave the community a floor to stand on while it figured out how to deliver reliably. The community now has the chance to build, on top of that floor, something far more ambitious.

The nine articles that follow are my, and our, best attempt to sketch what that looks like. Not as a rulebook. As a set of frames, stackable on top of the Scrum Guide you already know, aimed at the team you want to be running in 2030.

Over to You

Before reading Article 1, take five minutes and answer two questions honestly. What does your team currently treat as "done"? And when was the last time you saw proof that your users agree? The gap between those two answers is the territory this series is trying to close. See you in the first article.

Contributors

This series 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 Scrum Guide, Schwaber and Sutherland

Professional Scrum Competencies, Scrum.org

From Velocity to "Agent Efficiency": Evidence-Based Management for the AI Era, Scrum.org

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

You Can't Delegate Accountability to an Agent, Article 2 of this series

Refinement Is Not Solution Design, Article 3 of this series

The Increment Is a Lie, Article 4 of this series

The Sprint Review Is Broken, Article 5 of this series

The Knowledge Your Team Is Losing, Article 6 of this series

The Context Lake Is Product Management's New Core Artifact, Article 7 of this series

Transparency and the Biased Teammate, Article 8 of this series

Scrum Was Written for the Average Team. It Is Time to Aim Higher, Article 9 of this series