Once upon a time, the team was having trouble getting things Done. We asked why, five times. We found a root cause: we struggle to get backlog items Done because we aren’t Ready on sprint planning day.

So we brainstormed a Definition of Ready. We use it as a checklist to ensure we understand each backlog item well enough that every team member has a mental outline of the tasks required to get it Done. The Product Owner and the team agree that they are jointly responsible for ensuring two sprints worth of backlog items are Ready before sprint planning day. Now the team is better at getting things Done, and we’ll all live happily ever after.

Here is our Definition of Ready.

To be Ready, each product backlog item must have this information:

Definition of Ready
Short nameA canonical short name that we use as we discuss the backlog item
User storyIf we can’t describe it as a user story, it probably has no business value, and we probably shouldn’t do it. We use the “as a role …, I want …” style of user story (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template).
Use casesIf there are use cases that help describe the story better, we list them.
Current product behaviorMake sure we understand the product’s current behavior, before we implement this backlog item
Future product behavior and consequencesMake sure we have a clear vision of the product’s future behavior, after we implement this backlog item
Acceptance criteriaA list of testable conditions that tell us whether we implemented the backlog item successfully, following my acceptance criteria template
Test outlineOur test plan for this backlog item
Demo scriptOur demo script, showing how we will demo successful implementation of this backlog item. Acceptance criteria, test outline, and demo script obviously overlap each other–we think that’s OK because it helps us consider more aspects of Done.
Data storage concernsOne of our teams is working on a database migration project. Are there any data storage, data mapping, or other database related considerations for this backlog item?
Code flows and sequence, data flowWhat might the code look like? How might the data flow through the code?
Proof of concept / prototypeIf possible, we build a small prototype showing the feasibility of this backlog item, informing our other implementation decisions.
Review by other architect and tech teamWe love peer review. We force another architect and technical team to review our plan.
Security reviewWe have a security expert. We force him to give us advice.
UX specIf this backlog item has a user interface, we force the UX team to provide a specification.
Complexity/size estimateWe have estimated the backlog item’s size in story points.