Definition of Ready vs. Continuous Refinement

---

The Two Disciplines

The Definition of Ready (DoR) is an explicit checklist a story must meet before the team will take it into a sprint: acceptance criteria written, dependencies known, designs complete, sizing agreed. The discipline says: don't pull work that isn't ready.

Continuous refinement is the alternative discipline: the team refines stories continuously, in small conversations, accepting that some stories will enter the sprint at varying levels of readiness. The discipline says: keep the conversation going, don't gate.

The disagreement is genuine and important. Each approach optimizes for something real and breaks differently.

The Case for Definition of Ready

• Protects sprint focus. Half-formed work entering a sprint produces mid-sprint clarification interruptions, rework, and burnout.
• Creates pressure upstream. Stories that can't enter the sprint without meeting DoR force the PO and stakeholders to do refinement work earlier.
• Surfaces hidden dependencies. The DoR's dependency check often reveals work that needs to be coordinated with another team before commit.
• Improves estimation accuracy. Stories that meet DoR are better understood, which produces more honest estimates.

How DoR Goes Wrong

• The checklist becomes a contract. DoR turns into a stage-gate. The PO becomes responsible for "filling out" stories to a template. The conversation gets replaced by ticking boxes.
• Stories arrive over-specified. Detail accumulates to meet the checklist. The team receives stories with twelve mockups, fifteen acceptance criteria, and no remaining room for the conversation that should have happened.
• The DoR becomes a wall. If meeting DoR takes weeks, useful work waits indefinitely. The team starves while perfecting the queue.
• Backlog grooming time inflates. A team with a strict DoR can spend more time in refinement meetings than in development.

The Case for Continuous Refinement

• Just-in-time understanding. Stories are refined to the depth they need when they need it — not exhaustively in advance.
• Reduces wasted refinement. Stories that get descoped or reprioritized don't accumulate refinement debt.
• Keeps the conversation alive. Refinement happens in small, frequent doses rather than batched meetings, which keeps shared understanding current.
• Allows experiments. Sometimes the team genuinely needs to start a story to know whether it's the right shape. Continuous refinement permits this.

How Continuous Refinement Goes Wrong

• Stories enter sprints half-baked. Mid-sprint clarifications multiply. The team interrupts development to ask basic questions.
• The "conversation" is one-sided. The PO does all the refinement on the fly, in slack messages, during development.
• Estimation becomes meaningless. Stories without shared understanding cannot be honestly estimated.
• Drift to chaos. Without any baseline of readiness, the team accepts work it shouldn't have, and the sprint becomes a series of mini-discoveries instead of execution.

The Hidden Variable: Team Maturity

The right approach depends heavily on team maturity. Newer teams benefit from explicit DoR because they have not yet built the muscle of asking "is this ready?" reflexively. Mature teams can rely on continuous refinement because the question is so internalized it doesn't need a checklist. Pushing a mature team back into a strict DoR feels infantilizing. Pulling a new team into continuous refinement feels like chaos.

The honest framing: DoR is training wheels. The team's goal is to internalize the readiness questions to the point where the checklist becomes redundant — and then to drop it.

A Pragmatic Middle

Most healthy teams settle on:

• A short, lightweight DoR — three to five items — that names the truly non-negotiable preconditions (e.g., acceptance criteria exist, dependencies are surfaced, story has been discussed with the team).
• Continuous refinement for everything else, with refinement happening in small slices during the sprint and just before planning.
• Permission to take exceptions when the team and PO agree the value of starting outweighs the cost of incomplete readiness.

This stance treats readiness as a property the team verifies rather than a checklist the PO fills out.

Coaching Tips

Keep the DoR short.

Three to five items. A long DoR turns refinement into compliance and the conversation into checklist-filling.

Allow named exceptions.

Sometimes starting early is right. Let the team and PO agree to an exception explicitly — that's healthier than treating the DoR as inviolable.

Watch refinement-time inflation.

If refinement is eating more time than development, the DoR has become a stage gate. Loosen it.

Watch mid-sprint interruption count.

If the team is constantly stopping to clarify basics, continuous refinement is too loose. Tighten it.

Don't let the PO write all of DoR alone.

Ready is verified by the team. If the PO is filling in a template solo, the conversation has been bypassed.

Plan to retire the DoR.

It's training wheels. A mature team should eventually internalize readiness to the point where the checklist becomes redundant.

Summary

The Definition of Ready debate is about whether readiness is a property the team verifies or a checklist the PO produces. In practice, both extremes fail. The healthiest teams use a small, agreed-upon DoR as a backstop while doing most of their refinement continuously, and they trust each other enough to take exceptions when starting early is more valuable than waiting. The point is the underlying question — is this work ready to begin? — not the artifact that ends up asking it.

Back to The Great Agile Debates