Sprint planning is halfway through when someone points at a ticket and asks whether it is ready. The product owner says the goal is clear enough. The engineer says the API dependency is still unknown. QA asks what done will mean for analytics and edge cases. The room is not arguing about vocabulary. It is arguing about when work is safe to start and when it is honest to call it finished.
Definition of Ready and Definition of Done are two small agreements that protect different ends of the same workflow. Definition of Ready helps a team decide whether a piece of work has enough clarity to begin. Definition of Done helps a team decide whether finished really means finished. One protects the start from fog. The other protects the finish from wishful thinking.
A useful Definition of Ready does not require perfect certainty. If it does, nothing important will ever start. It asks for enough shared understanding: the user need is named, the expected outcome is clear, major dependencies are known, acceptance criteria are testable, and the work is small enough to discuss. Ready means the team can begin without immediately falling into avoidable confusion.
Ready should also leave room for discovery. Some work is ready because the next learning step is clear, not because every answer is known. A spike, prototype, or technical investigation can be ready when the question, timebox, and decision needed afterward are explicit. The problem is not uncertainty. The problem is pretending uncertainty is not there.
Definition of Done lives at the other end. It describes the quality bar before a story, feature, or increment can be considered complete. Code is merged. Tests are updated. Accessibility basics are checked. Analytics events are wired if the surface needs tracking. Documentation or release notes are updated when relevant. The feature is reviewed, deployed, and visible in the environment the team agreed on. Done means the work can leave the team with trust.
The danger is that both definitions can become theater. Definition of Ready can become a wall that blocks messy but valuable work from entering the sprint. Definition of Done can become a checklist people tick without thinking. The point is not to create paperwork. The point is to make hidden expectations visible before they cause rework.
Good teams keep the lists short. A Ready checklist with twenty items will be ignored or used as a weapon. A Done checklist that covers every possible concern will become background noise. The best definitions name the few things that repeatedly hurt the team when missed. If unclear acceptance criteria cause churn, add them to Ready. If analytics is often forgotten, add it to Done. Let the pain shape the agreement.
The two definitions also reduce personal negotiation. Without them, quality depends on who is reviewing, who is tired, and how close the deadline feels. With them, the team has a shared standard to point at. This is kinder for everyone. A developer is not being difficult by asking for acceptance criteria. QA is not being picky by asking how a case will be verified. Product is not moving the goalpost by expecting release notes if the team agreed that customer-facing change needs them.
They should not be owned by one role. Ready is not only a product owner responsibility, and Done is not only an engineering responsibility. Product, design, engineering, QA, data, support, and security may all carry part of the standard depending on the product. The agreement works best when the team sees it as a shared operating system, not a form one person fills out for another.
Definitions also need maintenance. After an incident, a missed tracking event, a confusing release, or repeated sprint spillover, the team can ask whether Ready or Done should change. Maybe dependency risk needs to be named earlier. Maybe feature flags belong in Done for risky rollout. Maybe performance checks matter for one category of work but not all. A living definition is more useful than a beautiful one that never changes.
The calm test is simple. Definition of Ready should help the team start work with fewer avoidable surprises. Definition of Done should help the team finish work with fewer hidden debts. If either one mostly creates meetings, delays, or blame, it has drifted away from its purpose.
The next time a ticket feels stuck between almost ready and almost done, it may help to ask which promise is unclear. Do we know enough to begin responsibly? Have we done enough to finish honestly? Those two questions are ordinary, but they save a team from many small confusions. Most delivery problems do not begin with bad intent. They begin when people use the same word, ready or done, while quietly meaning different things.