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:
| 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. |
Related:
- Hardening sprints? Sorry, you’re not Agile.
- If you’re not Done, you’re not Agile
- Acceptance criteria template
- Is it done?
- Jeff Sutherland’s paper, “Scrum and CMMI–Going from Good to Great: Are you ready-ready to be done-done?”, available here and here
