Why a Definition of Ready?
A Definition of Done (DoD) is an essential requirement for a Scrum team. The Scrum Guide says that a product backlog item (PBI) becomes an increment once it has met the DoD. Put simply:
PBI + DoD = increment
After spending time as a team working to define our DoD, another question came up. Should we have a Definition of Ready (DoR) and if so, when and why? We went back to the Scrum Guide for guidance, though we didn’t find a clear answer.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Scrum Guide raised more questions for our team than answers. How should we refine items to make sure they can be ready for selection? How can we be sure that something is refined enough? How can we refine PBIs well with both the development team and product owner (PO)?
Scrum is based on empiricism: knowledge comes from experience and making decisions now on what is known. In a complex environment, we won’t always have all the answers straight away. The three pillars of transparency, inspection and adaptation hold Scrum together and underpin empiricism. To help get us to a point where the team can accept a PBI into a sprint, we need three things:
- As the Scrum Guide above says, it needs to be small enough to be done in one sprint.
- It must be sized by the development team so the overall product backlog can be understood as a whole.
- It needs enough detail in the description so the development team can understand what is needed. The development team needs the detail to make a good forecast (meeting point 2).
Other than these three points, the Scrum Guide doesn’t say very much. It also doesn’t mandate any form of a DoR or even the idea of one. That’s up to the team to decide.
Our development team needed more. They wanted to have a codified DoR to ensure the PO was giving them enough ahead of any commitment. We created a DoR using a variation of William Wake’s INVEST checklist, which came out of his excellent book on Extreme Programming. While originally created to help validate user stories, we used an adapted version for our PBIs. We often use user stories in our PBIs, though not always. It helped keep me as a PO focused on creating good PBIs.
INVEST stands for:
Independent: of all other stories. Can this PBI be delivered independently?
Negotiable: does the PBI give the development team the creativity to come to a solution by themselves? Does the PBI include the essence of the requirement, empowering the development team to define the details?
Valuable: this is essential for any PO. Will this deliver value to our customers. Do they want this?
Estimable: does the development team have enough information to estimate the amount of work needed?
Small: is the PBI small enough for the development team to deliver in one sprint or does it need to be broken down further?
Testable: can the team test this? This might either be with an existing test or one which could be created in the future.
Our new DoR based on INVEST became the standard in our refinement sessions. Having this DoR also prompted some excellent conversations. For example, if the team didn’t have enough information to estimate, I would make sure they had enough. If a PBI’s value couldn’t be defined, the team would discuss its value or I, as a PO, would have to explain it.
Having this DoR also improved the quality of our sprint backlog, our sprint reviews and ultimately, our increments. It gave the team more confidence in committing to PBIs and meant we took more work into the sprint, which was then delivered, giving us a good increment to inspect.
A DoR and Kanban
In our Scrum evolution towards including more Lean principles in the way we work, a DoR served another purpose. Like the Scrum Guide, the Kanban Guide doesn’t have any reference to a DoR (nor would you expect it to). In Kanban terms, we see the DoR as an entry policy of our workflow. Moving something to ‘ready’ means it enters our system and the cycle time clock starts ticking. Like having a DoD, I don’t believe there is any incompatibility here between Scrum and Kanban. Our DoR is final check before something enters the system, through a clear policy in our Kanban Definition of Workflow.
