If you’re looking at the project ahead of you, “wondering” if you’re ready, you probably aren’t. This is where a narrowly defined list of checks comes in handy. We call it the Definition of Ready.
If you’ve been following along in order each week, you’ll find this article on the opposite spectrum of last week’s the Definition of Done. And for a good reason; where the DoD is your pre-determined list of requirements to know when you’re truly done, the Definition of Ready (DoR) is that gateway to getting started.
The Definition of Ready (DoR) is the assessment of User Stories to be immediately actionable.
For something, anything, to be immediately actionable is having the ability to do that “something” at this very moment. For instance, let’s say I wanted to become a cryptocurrency millionaire. My DoR would state first to have Bitcoin. I don’t have any; ergo, my dream of being a Bitcoin Millionaire is null, as I’m not even able to get past step one. 😞
In terms of an Agile/Scrum project, a User Story won’t meet the Definition of Ready if a team member cannot work on it right now. If a member of the Development Team walks up to the kanban board to move it from BACKLOG to IN PROGRESS, they will know it meets the DoR simply because it’s in the backlog. This should be a standing house rule. If it’s ready, it’s ready.
Why wouldn’t a story be ready? Perhaps a task doesn’t meet your defined requirements (that can include),
- Lack of completed dependencies (those items that are required to be finished before another item can start)
- Not having the proper equipment (you spilled coffee on your laptop, and it’s not working 😢)
- Is the User Story usable with the current amount of information on it? Maybe, maybe not.
💡 A note on Experimentation and Learning
While not a hard-n-fast rule, I do not consider anything under the category of education or experimentation an issue concerning the DoR. If the Development Team needs to research and learn some new API or experiment with a new Python library to complete the User Story, that’s part of the job and not a reason to consider something “not ready.”
Is your DoR…
When working through your team’s Definition of Done, as suggested by agility.im (with modifications).¹
Actionable — Is the item immediately actionable (doable) by the team? Does the team know what they need to do, and can they do it now? Is the task free from external dependencies that are not ready or available?
Refined — Has the item been through refinement before sprint planning? Is there a common understanding among the team on what the item is and how it will be implemented?
Value — What is the business value of the item? What is the value to the end-user? Is the value clear to everyone on the team? [Just know that you shouldn’t be working on it if it doesn’t create value.]
Estimated — Has the team estimated the item? Can it be completed in a single sprint?
Acceptance criteria — Has the item got clear acceptance criteria from the Product Owner?
Demo — Does the team understand how they might demo the item or discuss it in the sprint review once complete?
There are differing thoughts on how to determine a User Story’s/Task’s readiness. I’m of the “it’s either ready, or it’s not” camp. There’s no other way (to me) to do it. However, to be fair to the Scrum world and those who invented the method here’s one way used (but I’m not too fond of it 🤷♂️).
Bronze, silver, gold
Ranking your product backlog items readiness as bronze, silver, and gold can help teams visualize how much refinement needs to be done. Many gold items near the top can mean the definition of ready has been met, and the development team is well prepared for sprint planning.¹
Making the list
You’ll note that, unlike earlier articles, I’ve not given you a “how-to” for making your own DoR. I don’t think I need to. There’s nothing wrong with the ScrumMaster simply asking the team if they’re ready. Once you get a feel for what they can do, you’ll be able to determine what is good and what isn’t.
The true test is this: Can ___ work on and finish this task right now? Time is not of consequence here (unless the estimation states it should be done in a few hours, and they’re three days in).
A note of caution:
It is easy to misinterpret a Definition of Ready as a stage-gate within a pipeline of work, e.g., to insist that a full design or documented requirements must be provided for every work item before development can start, as that is what is on the Definition of Ready.
To be clear, the recommended use of a Definition of Ready is as a guideline for the team to determine if stories are ready to be worked on — a checklist of things to consider, rather than a stage-gate that to be fully satisfied for every story — always consider the context or situation for every story/item rather than blindly applying every aspect of the Definition of Ready to every object the team works on.