I covered the “Definition of Done” in my last blog. This blog takes the topic further, defining a “Definition of Ready (DoR).” While not an official artifact of Scrum, I have found having a Definition of Ready to be a best practice, and organizations that use this concept are far more successful than those that don’t.
What is a “Definition of Ready,” anyway?
Your Definition of Done (DoD) generally applies to your completed increments. The DoD covers most items and is widely applicable across most types of development work. So, what is a “Definition of Ready?” A Definition of Ready is specific to each User Story; having a definition ensures that User Stories are fully-baked – in other words, you have all the details needed to develop the User Story. Your DoR might include:
- A checklist
- A decision matrix
- Wireframes
- Data flow diagrams
- Data dictionaries
- Non-functional requirements
- Any other documents or artifacts necessary to complete the User Story
Interestingly, while Scrum has not officially adopted the Definition of Ready as an artifact, Scruminc.com (founded by one of the creators of The Scrum Guide, Jeff Sutherland) offers a short course on how to create one.
Why do you need a Definition of Ready?
Having a Definition of Ready gives you quality criteria that apply to the User Stories themselves. It also ensures that the developers can take action to develop the stories. The Definition of Ready is not mutually exclusive of the Definition of Done – rather, it enhances it by adding additional detail that you wouldn’t know at a higher level.
Who creates the Definition of Ready?
I generally collaborate with my Scrum Team to create a Definition of Ready at the beginning of a project. By doing this activity together, all parties have a say in creating the definition. The developers on the team are the typical recipients of the User Stories and Acceptance Criteria, so work with them to create a DoR that meets their requirements and expectations. When you mark a User Story as “ready,” there should be no outstanding questions or issues, and the item should be suitable for development.
Can you change your Definition of Ready?
Absolutely. There’s nothing written in stone here. Anything the team has agreed to can be re-negotiated any time it makes sense. I think it’s a good practice to regularly review both your Definition of Done and your Definition of Ready. The best forum for this tends to be the Sprint Retrospective. You don’t have to do it every time, but periodically, you should pull out these agreements and review them. If anything has changed, or the criteria for either artifact no longer make sense, then by all means – update them, so they continue to be relevant.
What if my team doesn’t think we need a Definition of Ready?
It’s easy to state the case for having a Definition of Ready. You can always give someone a link to my blog (just kidding – sort of). Most Developers hate it when they pick up a User Story that they “think” is ready to go, only to find that there are gaping holes, missing or wrong information, unverified assumptions, open decisions, etc. By ensuring all your User Stories meet a Definition of Ready, you can guarantee they are actionable. Your team will appreciate not having to go back and forth with questions about requirements, and they’ll develop an increment that meets everyone’s expectations.
Can I see an example of a Definition of Ready?
You sure can. Here’s a sample off the top of my head:
- The User Story is written in the proper format (as a __, I want __, so that)
- The Acceptance Criteria are documented and approved by the Product Owner
- Any supporting documentation or models are attached to the User Story
- There are no outstanding decisions that need to be made
- Any assumptions have been validated
- Negative scenarios have been addressed (not just the happy path)
- Each criterion is pass/fail
- The User Story is in the “Ready” column on the Kanban board
See? It’s not that difficult to come up with a Definition of Ready, but can you see how it would be helpful to improve development outcomes?
Final Thoughts
I know this is a short blog, but I thought the topic was still worth discussing. I learned how important having a Definition of Ready is based on my experiences as a consultant (and not having one). By investing a small amount of time together to create the definition, you will ensure you have high-quality User Stories and Acceptance Criteria that are actionable, testable, and verifiable. Combined with your overall Definition of Done, you will produce high-quality, trusted increments that delight your customers.
How about you? Does your team have a “Definition of Ready?” If so, what does it include? If not, do you think having one would be helpful? I would love to hear your thoughts in the comments below, so let me know!