How Definition of Ready and Definition of Done help teams to achieve quality deliverables
Agile way of working is having two important popular concepts . These two concepts are Definition of Ready(DoR) and Definition of Done(DoD). You would often hear these terms used by teams. These concepts quality product and make sure that team’s delivery is aligned with sprint goal and product goal. These are kind of working agreements between team and management/product that what all things team would need to deliver and when any piece of requirement would be called done. So, let’s talk about these two terms in little more detail here.
Definition of Ready
First, I will talk about Definition of Ready or DoR. What is it actually? How it helps team? And why it is important. So Definition of Ready is kind of a check list which team agreed upon and prepared with in alignment of their mode of functioning. This list is a parameter or criteria for team to decide whether any story is ready to be taken in the sprint.
Few possible items can be part of Definition of Ready like –
- Is design completed for the requirement?
- Is requirement got freeze?
- All questions/queries related to story are answered?
- Is it ready to be committed in the sprint planning?
- Is test data available for team to test?
- Is environment available and ready for development and testing?
- Is story having acceptance criteria clearly defined?
- Is story adhering to INVEST?
Photo by David Iskander on Unsplash
Definition of Ready can vary from team to team. One DoR may not be feasible or right for another team. It should be prepared by team before they start working on the project.
Definition of Done
Next we have is Definition of Done or DoD. It is basically list of items to make sure when we can call any piece of requirement done and can be showcased at sprint review. There may be different notion for different people. For developers, a story is done when they are done with development activities. For a tester, it is done when all the testing activities are done. But will a story be really done if these two activities are done ? May not be. There is a purpose for the story, there are some acceptance criteria, there are statutory requirement, there are some release requirements and there may be some security requirements. So merely doing development and testing would not guarantee that any story would be done. Again this is list which is designed based on sprint goal, product goals and with which team agreed upon and prepared with in alignment of their mode of functioning.
Few possible items can be part of Definition of Done like –
- Are acceptance criteria met?
- Is story tested and verified?
- All severe open defects are tested and closed, and no high priority defects are open?
- Is automation testing, if applicable, is done?
- Is story fulfilling the release requirement?
- Are all review comments are addressed?
Definition of Done is usually defined at project/product level and team can have their own items added to that. So basically, these two concepts are there to make sure that once team commits some work in sprint, they don’t get blocked or face any challenges which could have been resolved before team started working on them. Also, different people in team may have different ways to call some story done, but actually the ‘DoD’ should be defined based on the product goal and requirement, and if any story not meeting ‘DoD’, it should not be called done and should move either to next sprint or back to backlog.
Hope this article would give you some idea about ‘DoR’ and ‘DoD’ and help you to implement with your team appropriately.