I have always been a big fan of preparation, and for every project and team that I have supported or led in the past, be it in the realm of a Project Manager, a Scrum master, an Agile Coach, or a Delivery Lead, I always believed a crucial part of our success as a team or teams in what we ship to our customers was hugely contingent on our preparation.
While one of the Agile Manifesto values talks of ‘individuals and interactions over processes and tools,’ we should always treat this statement cautiously.
Processes and tools have the potential to make things easier, and today, I invite you to join me in exploring these two fundamental concepts, which are ingredients and garnishments to the quality of deliverables we push out as a team or a business.
What are these two concepts?
The definition of Ready (DoR) and Definition of Done (DoD).
In the ever-evolving and dynamic world of agile product delivery, we must continue exploring ways to help make the planning and delivery process seamless, and having a DoR and DoD can help facilitate this process.
Ok, now I will spare you the rant, and let’s quickly explore these two concepts, as most people often confuse them to mean similar things.
Firstly, what is the Definition of Ready (DoD) in Agile?
In Agile Product Delivery, business requirements are typically decomposed into user stories, which are granular units of customer value or a business functionality to be delivered within a Sprint. Typically, agile teams will go through the process of grooming to prepare requirements that will make itself into a Sprint, and for a given story to be included in a Sprint, it must meet some essential prerequisites.
We refer to these prerequisites as the Definition of Ready (DoR). In another way, DoR serves as a checklist that a user story or product backlog item (PBI) must meet before it can be picked up by a developer for implementation.
And why is it important to have one?
It provides clarity, shared understanding, and confidence that a story can be implemented within a Sprint. It may vary from one environment to another or from one business establishment to the other; however, over the years, I have found some fundamental DoR requirements that teams should establish to make the process of planning seamless.
What are some of these requirements?
- The story or PBI item has clear acceptance criteria that have been discussed and agreed upon.
- Internal and external dependencies related to the PBI item or story must have been identified and resolved. It can be frustrating to start a story only to find out an underlying dependency was missed.
- The level of effort (LOE) to implement the story must be determined and feasible to be completed within the scope of a Sprint.
- UI/UX screens and mock-ups, wireframes, data schemas, and models must have been developed, finalized with the team, and attached to stories.
- Lastly, when do we anticipate releasing the piece of functionality?
By having a common agreed DoR, agile teams can ensure they approach their Sprint well-prepared.
While this is not an exhaustive list, I have found these to be very pivotal to getting stories ready for implementation. What other criteria have you used in the past to qualify a PBI ready for implementation?
Now that we have seen the DoR and what it has to offer, let’s explore its cousin, the Definition of Done (DoD).
What is the Definition of Done (DoD)?
Before the Product Owner marks a story and approves it as done, it must also fulfill some fundamental requirements. Look at it as a checklist that a user story must meet before the Product Owner can approve it for shipment, and it helps determine the quality of our deliverables.
Some elements that can be found in a Definition of Done (DoD) standard include.
- The code has been peer-reviewed and approved.
- Different tests have been executed and passed, including Unit tests, Integration tests, User Acceptance Tests (UAT), E2E Tests, performance tests, and Regression tests.
- Results of test cases executed attached to stories, stories demoed and determined to meet business logic (s).
- Functional requirements are met based on UI screens and mock-ups.
DoR is the ingredient that determines the quality of the deliverable, while DoD will decide if we can serve the deliverables to the customers.
Who determines the DoR and DoD Standards?
It is not the Scrum master. It is not the Agile Coach or the Product Manager. It is a collaborative process where team members work together in a working session to identify and agree on criteria for DoR and DoD.
We have often heard that quality should be built into the process, and having these two standards is one of the many ways that we can use to build quality.
Do you currently have a DoR and DoD standard in your environment?
Please use the comment section below to suggest other metrics you have used in the past so we all can learn from them.
- Interested in SAFe 6.0 Scrum master training and Certification?
- Are you interested in SAFe 6.0 Release Train Engineer (RTE) training and Certification?
- Are you interested in SAFe 6.0 Product Owner training and Certification?
- Are you interested in Jira training?
- Are you interested in Scrum master, Release Train Engineer, or PO interview prepping?
Feel free to browse our training and certification page.
Let us know other topics you’d like us to share our knowledge on and we will gladly do so.