Article 3 of 9 in the series.

Picture a refinement session that looks, from the outside, like a model of good practice. Ten Product Backlog items reviewed. Acceptance criteria tightened. Story points assigned. Dependencies flagged. Everyone leaves on time. Every item looks ready for the next Sprint.

Now ask the room why any of those ten items will move the needle for the product. The conversation was about how, and only about how. In an AI-powered world, that is the wrong conversation to be having.

In the first article of this series, I proposed a Definition of Value as the team's anchor artifact. In the second, I argued that the three Scrum accountabilities concentrate, rather than dissolve, as agents enter the work. This third article goes inside the practice where those two threads meet and get operationalized, every week: Product Backlog refinement. Worth naming up front, because the rest of the article rests on it: refinement is, per the Scrum Guide, an ongoing activity, not one of the five Scrum Events. The five Events are the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. Refinement is the practice that makes those Events work.

This is a visionary piece, not a predictive one. I cannot tell you precisely how refinement will change in the next five years. I can share how a room full of experienced Professional Scrum Trainers thinks it must evolve, and why the shift matters for your team this Sprint. 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.

Refinement Was Decomposition When Delivery Was Scarce

For most of my career, refinement has meant one thing in practice: take a Product Backlog item, sharpen the acceptance criteria, decompose the work, estimate it, and hand it to the Developers in a form they can build inside a Sprint. That is a reasonable use of the practice when the bottleneck is build capacity. The Developers are expensive and slow. The job of refinement is to keep them fed with work they can start immediately.

Make no mistake; the Scrum Guide's description of refinement has always allowed for more than decomposition. Refinement is described as adding detail, order, and understanding. The Guide has never forbidden option thinking. Teams shrank refinement, not the Guide. The bottleneck demanded it.

The New Scarcity Is Option Quality

AI agents have moved the bottleneck. Option generation is no longer expensive. Acceptance-criteria drafting is no longer slow. Code scaffolding is no longer the constraint. An agent can produce three viable approaches to a feature in the time it used to take one Developer to finish the first sentence of a design sketch.

What is now scarce, and what was always the most important thing, is option quality: knowing which bet to make, why we are making it, and what we expect to learn. That is where the human judgment lives. That is where refinement must now concentrate its attention.

The Option Frame

So what should your team be doing, in refinement, instead of decomposition? Replace the "definition of ready" checklist with a four-row structure I will call the Option Frame. Put it on the wall, next to the Definition of Value from the first article.

Outcome. What change in user or business behavior are we betting on? This sentence must tie back to a line in your Definition of Value.

Options. What are the three most plausible ways we could move that outcome? An agent is excellent at generating these. The Product Owner and the Developers are accountable for pruning and pressure-testing them.

Bet. Which option are we choosing, and why? This is the human judgment call. The Product Owner signs. The Developers confirm feasibility. An agent cannot hold this row.

Evidence. What will we see if the bet is working? What will we see if it is not? Think in terms of leading indicators, adoption signals, and falsifiable counters. An agent can help synthesize evidence definitions from historical data. The team still owns which evidence counts.

If any row cannot be answered, the item is not refined. It is not ready for a Sprint. It is an unframed option pretending to be a commitment.

Where Agents Belong, and Where They Do Not

The Option Frame also makes the human-agent division of labor obvious.

Agents belong in Options: generating, scaffolding, and varying. They belong in Evidence: proposing measures, querying historical data, drafting the dashboard queries before the Sprint starts. They do not belong in Outcome or Bet. Those rows are where product judgment, stakeholder alignment, and accountability live. Those are the rows that, in Article 2, I called the sharpest points of the team's operating model.

Put differently: agents generate and synthesize. Humans frame and decide. Refinement is where that distinction becomes operational.

A Provocation About the Product Backlog Itself

Worth naming, in a sidebar, a conversation that kept returning to the floor in Amsterdam. If an agent can, on demand, generate the right ten options for the right outcome at the moment the team needs them, does the team still need a long, ordered Product Backlog in the old sense? Or does the Product Backlog shrink to a short list of live bets, a current Sprint's worth of framed Options, and a working Definition of Value that the agent can query to regenerate the rest?

Make no mistake; I am not arguing the Product Backlog is going away. The Scrum Guide's Product Backlog, an emergent, ordered list of what is needed, is as correct today as in 2020. What I am arguing is that the artifact many teams maintain, a thousand-item, over-groomed, never-read list, is a delivery-era habit that is about to age badly. The Product Backlog of an AI-powered team is likely to be smaller, sharper, more opinionated, and more tightly coupled to the Definition of Value than most of the tools teams are using today assume. That is a provocation worth sitting with, even if your team chooses, for now, to keep the backlog you have.

What This Looks Like in Practice

Picture a fintech team refining a Product Backlog item about improving a cross-border payment flow. The classical refinement session would tighten the acceptance criteria, argue about edge cases for three currencies, and assign a five-point estimate. Everyone would leave satisfied.

In an AI-powered refinement session, the Product Owner opens the Option Frame. Outcome: reduce first-payment abandonment for new SMB customers by thirty percent, tied directly to the team's DoV on activation. Options: the team uses an agent to generate three plausible variants: an inline currency suggestion, a pre-payment FX transparency panel, and a one-tap saved-recipient flow. Two Developers spot a hidden risk in the first variant inside ten minutes. Bet: the FX transparency panel, because the team hypothesizes that abandonment is driven by uncertainty, not friction. Evidence: SMB activation conversion in the first payment flow, measured over fourteen days; support tickets mentioning FX; average dwell time on the panel. Done. Twenty-five minutes, one item, one bet the whole team can explain.

Now compare the two. The classical session produced a well-decomposed item. The Option Frame session produced a well-framed bet. Both look like refinement. Only one is what refinement needs to be.

Four Things You Can Do in Your Next Sprint

Put the Option Frame on the wall. Four rows. Visible in every refinement session. If you have the Definition of Value up already, the Outcome row should literally point at it.

Use an agent to generate three to five options for one item. Not to pick one. To surface them. The Product Owner and the Developers then prune, pressure-test, and bet. Time-box the generation step to ten minutes.

Retire the "definition of ready" as a checklist, replace with the Option Frame. Your old definition of ready was trying to do this job. It just never had the structure to force the conversation. The Option Frame does.

At the end of refinement, read out the Bet and the Evidence. Out loud. If anyone on the team cannot restate them in one sentence, the item is not ready. Send it back. Not to reject it. To sharpen it.

The Turn

For thirty years, refinement has been the practice where teams broke work down. In an AI-powered team, refinement becomes the practice where teams frame their bets. Decomposition gets cheaper every month. Judgment does not. The most valuable thirty minutes in your Sprint, once agents are in the room, are the ones where you decide what you are choosing not to build, and what you expect to learn from what you do.

Over to You

Look at the last three items your team shipped. For each, ask: what was the outcome, what were the other options, what bet did we make, and what evidence proved us right or wrong? If you cannot answer in four sentences, the refinement conversation is the place to fix it. Not the Sprint Review.

The next article asks an uncomfortable follow-up. If refinement is where bets get made, the Increment is where bets get tested. Then why do so many teams ship a "usable" Increment that nobody actually uses? 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

What Is Product Backlog Refinement?, Scrum.org

The Scrum Guide, Schwaber and Sutherland

Continuous Discovery Habits, Teresa Torres

Inspired, Marty Cagan

Outcomes Over Output, Josh Seiden

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