A Definition of Ready can be a useful working agreement for a Scrum team or it can be a step away from healthy, dynamic collaboration back into the world of too much process. So, how do you know if you need a Definition of Ready? And if you do need one, how do you ensure it’s a tool for healthy collaboration?
Two Questions
Scrum specifies that teams should have a Definition of Done, a working agreement to clarify what “working software” means for them. But what about a Definition of Ready, a working agreement to align on what backlog refinement needs to be complete before the team pulls work into a Sprint? Whether you need one or not probably depends on two questions: “is the Product Owner a trusted collaborator?” and “is the work complex or complicated?”
In its worst form, a Definition of Ready overlays a detailed stage-gate process on what is intended to be a lightweight, collaborative approach. It focuses heavily on written documentation and formalized checklists. In its best form, a Definition of Ready helps a team have the right conversations during Product Backlog Refinement so that the Sprint Planning meeting is fast and effective.
The Product Owner
On a team where the Product Owner is a collaborative, trusted team member, a Definition of Ready might be something as simple as, “We understand the items at the top of the Product Backlog well enough to decide if they would fit in a Sprint.”
One bit of advice we often share is that items should be small enough that 6-10 of them would fit in a sprint. A team following that advice only needs to ask “Could 6-10 of these fit in a sprint?” If the answer is “yes,” those items are ready. If the answer is “no,” or, “I’m not sure,” then they may need to split them down, have more conversations about what they mean, specify some examples, etc.
If you look for example Definitions of Ready online, you’ll often see things like:
- The item is valuable
- The item is estimated and small
- The item has acceptance criteria
- Dependencies have been identified
- Etc.
Notice that each of these items on the checklist is attempting to define the steps a Product Owner might take to help the team understand a backlog item well enough that they could pull it into a sprint.
Complicated vs. Complex
If the work is complicated (in Cynefin terms, meaning predictable), specifying a lot of detail up front makes sense. With good analysis, we know what to build and how to build it. If that’s true, a definition of ready ensures that good analysis is done before we get to Sprint Planning.
If, however, the work is complex (meaning we will only really understand what to build and how to build it as we get started doing the work), then we’re better off with a clear hypothesis and a simple design of the first probe. The Definition of Ready that calls for clear acceptance criteria, for example, will lead to analysis paralysis or to a faulty plan. Better to pull that item into a sprint with just enough detail to start and then collaborate as additional detail emerges.
Experiment
So, back to the original question, do you need a Definition of Ready?
-
- If it feels like you’re either spending too much time on backlog refinement or you’re ending up doing backlog refinement at the start of Sprint Planning, you may benefit from a working agreement about how much refinement is enough.
- If you do choose to try a Definition of Ready, keep it as lightweight as you can. A simple agreement could be, “We agree to refine backlog items only until we can say with reasonable confidence, ‘We believe 6-10 of these could fit in a typical sprint.’”
- If you find you need to specify more detail in your Definition of Ready—perhaps the simple agreement leads to too much debate—consider tagging your backlog items as “mostly complicated” or “mostly complex” and apply a different Definition of Ready to each. Complicated items benefit from more planning. Complex items benefit from getting started and letting details emerge.
If you try a Definition of Ready for your team, treat it as an experiment. Agree on a hypothesis—what do you believe will happen if you try this? How will you know if it’s working or not? Then, review the results of your experiment after a few sprints. Don’t just mindlessly grow your process. Shape it to fit your team’s needs.
Learn More
Certified ScrumMaster Training (virtual, instructor-led)
Certified Scrum Product Owner Training (virtual, instructor-led)
Advanced Certified Scrum Product Owner Training (virtual, instructor-led)
2-Week Backlog Makeover Course (online, self-guided)
80/20 Product Ownership Course (online, self-guided)
Last updated