Definition of Ready Template for Agile Teams

The Definition of Ready defines when a story is clear enough to start working on. The [Definition of Done](/templates/definition-of-done-template) defines when a story is complete enough to ship. Ready is the entry gate. Done is the exit gate. Both are team agreements that reduce ambiguity.

Not necessarily. Bug fixes and technical spikes may skip design requirements. The core items (clear acceptance criteria, estimation, no blocking dependencies) should apply to every story. Create lightweight variants for non-standard work.

The [product manager](/glossary/associate-product-manager) owns story clarity, acceptance criteria, and business context. The designer owns mockups and interaction specs. Engineering contributes to technical approach and estimation. Readiness is a shared responsibility, not one person's job.

If a critical bug or business emergency requires pulling an unready story into the sprint, do it. Document what is missing and accept the risk of mid-sprint clarification. But track these exceptions. If "urgent unready stories" happen every sprint, the real problem is planning discipline, not emergencies.

In the short term, it adds friction to refinement. In the medium term, it reduces mid-sprint churn, carry-overs, and rework. Teams that adopt a DoR typically see [velocity](/glossary/velocity) stabilize within 3-4 sprints because they stop starting work they cannot finish. The [Scrum vs. Kanban comparison](/compare/scrum-vs-kanban) discusses how both frameworks handle work-in-progress limits.