A definition of ready and definition of done checklist

Definition of Ready is the team's agreement that a backlog item is understood well enough to pull into a sprint. It is not a promise that nothing will change. It is a bar the item has to clear before planning treats it as a candidate.

A useful Ready check is short enough to use in refinement. The outcome is clear. Acceptance is written in a way the team can test. The item is sized. Dependencies are visible. No known blocker is sitting on it. It is small enough that the team can finish it inside the sprint they are about to plan.

If those checks fail, the item stays in refinement. Pulling it anyway moves the discovery into the sprint, which is how committed work grows after planning and how spillover becomes normal.

Definition of Done is the team's agreement that an increment is actually finished. The acceptance criteria are met. The work is integrated and tested to the level the team agreed. Known defects are not left inside the increment and then called complete.

Done is a property of the increment, shared by the team, not a status one person sets because the coding is over. When a sprint full of bug fixes is counted the same as a sprint that shipped the commitment, the delivery number stops meaning what the team thinks it means.

Defects found after the team called the work Done are escaped defects. They belong in the quality picture, separate from the count of work that met the commitment.

Refinement. Walk the next candidates against Ready. If the outcome, acceptance, size, or a dependency is still open, that item is not a planning candidate yet. Pointing an item that fails Ready only makes the backlog look fuller than it is.

Sprint planning. Pull only items that meet Ready, and only as many as recent delivery says the team can finish. A backlog of unready stories is not capacity. Planning is the moment to notice that gap, not the moment to invent the missing acceptance criteria.

During the sprint and at review. Completed means Done. Work that still has open defects, or that was added after the commitment, is part of the sprint story, and it is not the same number as work that met Done. The review shows the increment that passed that bar.

Ready is an intake question: is there enough refined work for the sprints ahead? Sprint Vitals puts backlog health on the Scrum board for the next three future sprints — refined points against trailing velocity, plus stale pointed stories and blocked work — so the team can see that before planning, not after the sprint has already started thin.

Done is a delivery and quality question. Delivery keeps the commitment, what was added or removed, what completed, and what spilled. Quality stays beside that count: defects created, defects closed, and escaped bugs, so a sprint spent fixing defects does not look like a sprint that shipped the commitment.

A Jira admin approves Marketplace apps for the site. If you are the scrum master, send them the install link. If you already have Sprint Vitals, the manual explains how to read those numbers on the board.