The gate that became a traffic jam
Every agile team knows the Definition of Ready. It’s the checklist a user story must pass before a team pulls it into a sprint. Stories written? Acceptance criteria defined? Dependencies identified? Design complete? If the box isn’t checked, the story stays in the backlog.
The intent is good. Ready guards against starting work that isn’t well understood. In theory, it prevents waste.
In practice, something else happens. The backlog fills with stories that are “almost ready” — waiting on one more dependency, one more sign-off, one more piece of information. Nobody owns this pre-work queue. The Product Owner assumes the team will ask when they need something. The team assumes the PO won’t hand them unfinished work. The work sits.
This is the hidden cost of a rigid Definition of Ready: it creates a state of limbo where work is defined enough to be tracked but not defined enough to be started. And because nobody owns that limbo state, it persists indefinitely.
The teams with the best flow do something different
I’ve been watching how high-flow teams handle readiness. They don’t abandon the concept — they just flip the model. Ready becomes a conversation starter, not a gate.
Instead of requiring every checklist item to be complete before the sprint, these teams agree on what “ready enough” means. They pull a story in when the core intent is clear, the key acceptance criteria are understood, and the team has a shared mental model of what success looks like. The remaining details get worked out in the first day or two of the sprint, during refinement and discovery.
The difference is subtle but powerful. The checklist-based approach optimizes for certainty before starting. The conversation-based approach optimizes for flow — starting sooner, learning faster, and filling in details as the work progresses.
This isn’t about lowering standards. It’s about recognizing that uncertainty is best resolved by doing the work, not by pre-planning the work.
What happens when AI enters the picture
This matters even more as teams layer AI-assisted development into their workflows.
AI tools excel at generating drafts, options, and analyses quickly. But they also introduce a new kind of uncertainty — the output is probabilistic, not deterministic. A rigid Definition of Ready breaks when the inputs are inherently uncertain. The checklist never gets fully checked because the AI’s output can’t be fully predicted before the work starts.
Teams that use Ready as a conversation starter handle this naturally. They pull in an AI-generated draft with a note that says, “This is directionally correct — we’ll validate and refine in the sprint.” The work starts, learning happens, and the definition firms up through doing.
A team stuck on a rigid DoR will hand the AI output back to the PO and say, “This isn’t ready yet.” And the work stalls at the gate.
What to try instead
If your team’s Definition of Ready feels more like a bottleneck than an enabler, here are three things to experiment with:
1. Distinguish between “ready to start” and “ready to complete.” Some things genuinely need to be resolved before starting (the core business outcome). Many things can be resolved during the sprint (edge cases, UI details, exact acceptance criteria phrasings). Be explicit about which is which.
2. Set a timebox on the pre-work queue. If a story has been in the backlog for more than two sprints waiting for a Ready checkbox, have a conversation about whether it should be descoped, redefined, or started with what you know.
3. Retro your Ready criteria. Treat your Definition of Ready like any other team practice. If it’s creating friction without improving outcomes, change it. The best teams revisit their DoR quarterly.
The goal isn’t to eliminate readiness as a concept. It’s to make sure your Definition of Ready is accelerating flow, not creating a hidden bottleneck in the space between the backlog and the sprint.