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
Criterion Description
Short name A canonical short name that we use as we discuss the backlog item
User story If 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 cases If there are use cases that help describe the story better, we list them.
Current product behavior Make sure we understand the product’s current behavior, before we implement this backlog item
Future product behavior and consequences Make sure we have a clear vision of the product’s future behavior, after we implement this backlog item
Acceptance criteria A list of testable conditions that tell us whether we implemented the backlog item successfully, following my acceptance criteria template
Test outline Our test plan for this backlog item
Demo script Our 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 concerns One 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 flow What might the code look like? How might the data flow through the code?
Proof of concept / prototype If possible, we build a small prototype showing the feasibility of this backlog item, informing our other implementation decisions.
Review by other architect and tech team We love peer review. We force another architect and technical team to review our plan.
Security review We have a security expert. We force him to give us advice.
UX spec If this backlog item has a user interface, we force the UX team to provide a specification.
Complexity/size estimate We have estimated the backlog item’s size in story points.