Table of Contents
To ensure the high quality of your end products, it is important to establish quality checks before delivering them to a client. Any product must be checked for bugs and other sorts of issues beforehand. But in order for those checks to be productive, there has to be some structure and a full understanding of what exactly a product should look like. That’s where you can implement Definition of Ready (DoR) and Definition of Done (DoD).
What is DoR and DoD
Basically, DoR and DoD are criteria that are agreed-upon with a team and a client concerning the user stories (software features written from the user perspective). Those criteria are necessary for the team to confidently proceed to the next step of development. User story requirements that haven’t passed DoR can’t be included into Sprint, as well as implemented user stories cannot be deployed on production until they pass DoD.
Discussing DoR and DoD with a team helps to avoid confusions and blockers during work – as soon as everybody understands when exactly a product is 100% finished, you don’t risk creating buggy and vague features that eventually lead to lots of unexpected expenses.
Definition of Ready
DoR is the first gate that a user story must pass. In simple terms, it’s a set of standards meeting which indicates that a team can start a Sprint.
Typically, such set includes :
- Written acceptance criteria – a set of conditions that a product must meet in order to be accepted;
- Documented requirements;
- User story presented to the team;
- User story estimated;
- UX/UI design ready and attached to the task;
- UAT and test cases prepared by the QA team.
The main goal of DoR is to establish clear requirements for development. Having well-documented requirements helps to conduct proper evaluation and prioritize features, so that a backlog for the team is planned precisely.
DoR Utility
While the main goal of DoR is clear, it’s also important to highlight the practical use of this phenomenon. It can help your team:
- Avoid starting work on features that don’t have a clear definition of completion criteria. The team will understand when the User Story is considered finished, and what needs to be done for this.
- Not to waste a lot of time on lengthy discussions of poorly thought-out tasks. A pre-processed task will save the time of the entire team. Calculate how much time it takes to discuss a “bad” task for one person. Then multiply by the number of people in the team. Then – by the number of such tasks.
- Focus on things that are as “safe” as possible. One of the strongest demotivators is the functionality that is thrown into the trash.
- Involve everyone in the discussion of tasks. Firstly, it motivates the team. Secondly, it helps to reveal each team member as a specialist. Thirdly, the developers will offer their vision of the problem. During the discussion, other solutions may arise that will be radically different from the original idea.
Definition of Done
DoD is the second gate that a user story must pass through. It is a set of standards, indicating that a project is completely finished and ready to be released.
Such set usually includes:
- Completed code review;
- Tests successfully passed;
- Product owner’s approval of work;
- Ready user documentation.
The main goal is to have well-documented functionality, minimize the number of bugs, and get approval from the product owner.
Definition of Done VS Acceptance Criteria
In this article we’ve already mentioned the term ‘Acceptance Criteria (AC)’ and provided its meaning. It is true that it looks similar to DoD’s, and some may find them confusing.
Definition of Done is about a proper building process, while AC is about the feature itself.
For example, a user story of adding a payment system has an acceptance criteria such as “Users can save a credit card in their profiles” or “Users can select PayPal as a payment method”. DoD includes a corresponding criteria such as “User tests are passed successfully”.
Final thoughts
For a better understanding of how DoD and DoR work in the iteration cycle, look at the picture below. As you can see, DoR and DoD serve as a gate that a feature must pass through before it’s deployed.
Of course, for each project and team, DoR and DoD are different. Developing good criteria requires discussion with the team and a product owner, so it takes some time and effort to develop them.
It may look like having Definition of Ready, Definition of Done and Acceptance Criteria all in one place is too much. However, having a transparent working process on each user story can actually increase team speed and improve the overall quality of the end product. This leads to a better user experience, and results in more satisfied customers and increased revenue. The clients’ engagement and satisfaction with the team’s work directly impact the satisfaction of the end users.
