Around the world, project delivery has become more focused on getting things done right and on time. But, unfortunately, with rapidly evolving processes, we often lose track of the steps to ensure quality work is delivered.
NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.
Organizations now know that it is more efficient to start a project knowing the acceptance criteria for what needs to be done to help minimize mistakes in delivery objectives or delays with client signoff.
In this article, we will focus on two concepts that help agile project teams ensure:
- they are ready when they get a green light for a project deliverable; and
- when the project is complete, deliverables are as intended at the start.
It is important to note that deliverables can relate to releases for a feature, completion of a sprint, or the release of a final product.
DoR vs. DoD
Mixing the concepts of Definition of Ready (DoR) and Definition of Done (DoD), not defining them according to their intended purpose, or not establishing them before the project execution, leads to significant undesirable outcomes. This can lead to misplaced priorities, missing design features, overlooked bugs, and much more.
It is critical to confirm these definitions early to reduce risks during execution. If you don’t establish these standards at the beginning of a task, the team members may focus more on simply completing the task rather than following all the required steps to achieve the right outcome.
Let’s start by defining both concepts: Definition of Ready (DoR) and Definition of Done (DoD) in Agile project implementation.
Definition of Ready
The Definition of Ready (DoR) defines the criteria that a user story must meet before being considered for estimation or inclusion in a sprint. Hence, before accepting a user story in a sprint, the team must agree upon the Definition of Ready and show the acceptance criteria for that user story to be considered complete.
It is important to note that the acceptance criteria does not necessarily have to be effectively 100% complete. It may be updated or modified as the sprint progresses. The DoR may only be considered “ready” when the implementing team is sure that they can successfully deliver the user story or task in the sprint.
The DoR acts like a contributor to the user story or task. It ensures that the necessary information to define a user story is ready, captured, and understood within that story. Note that DoR depends on the team members and the underlying context.
Following certain basic rules while creating the DoR would enable it to capture as much information as possible early on in the user story. These rules may include a proper formulation of user stories, a clear understanding of the acceptance criteria by the development team, recognizing potential blockers and dependencies, an understanding of the performance indicators, and measurement criteria by the team.
Note that DoR is never fully defined at the beginning. As you work on a user story, the acceptance criteria may be updated, leading to updating of the DoR to capture new realities and expectations. This ensures that the DoR is robust enough and captures all the necessary pain points. Also, the team better understands what is meant to be done, the proper way to do it and ensures minimal to no rework of user stories.
INVEST Principle
In certifying a user story or task as ready for a sprint, the DoR must follow the principle of INVEST.
A good user story should fit the following criteria:
- “I” independent (able to deliver value and clearly outline dependencies)
- “N” negotiable (clearly understand What & Why)
- “V” valuable (clear value of what will be delivered)
- “E” estimable (able to understand complexity and effort)
- “S” small (can plan work with moderate certainty)
- “T” testable (able to test to ensure it meets acceptance criteria)
The principle of INVEST helps story writers remember the industry-accepted set of criteria to ensure the quality of a user story. If a user story fails to meet this set criteria, the scrum team may choose to revamp it. In some cases, the team rewrites the story to meet the INVEST criteria better.
Definition of Done
The Definition of Done (DoD) is a checklist of activities and artifacts that must be completed for every user story. It essentially declares that the user story or task is fit and completed as agreed upon by the development or scrum team.
A DoD declares a completed user story as ”Potentially Shippable” and grants a certain ”confidence” that what the agile project team developed in the sprint is, in fact ”done” and ”done right”. A DoD also signals that the developed product doesn’t have any work left to be completed (”undone work”) and is ready to be delivered or shipped.
For teams to guarantee that a final product is “shippable,” there must be a well-defined and agreed-upon DoD to validate all that was laid out in the DoR concerning the development of the product.
Some common tasks included in a DoD are:
- Development
- Adherence to Design/Development Standards
- Testing
- Integration
- Bug Remediation
- Deployment
Generally, it is important to note that the DoD and acceptance criteria come together during acceptance tests of a completed sprint. When applied to a sprint, the DoD will determine if the items listed in the acceptance criteria document have been met and therefore done.
Conclusion
Establishing and adhering to the Definition of Ready (DoR) and Definition of Done (DoD) can help agile project teams better prepare for projects and complete their deliverables with higher quality and customer satisfaction. At the start of a project, the DoR can help ensure all relevant information for a task is captured for development teams to begin work and have a clear direction for the anticipated outcome. Well-prepared stories are a great start to delivering quality sprints and can lead to increased sprint success. DoD ensures all teams deliver quality work following best practices while maintaining a clear and transparent approach to a unified “done”.
This post was published under the Agile Community of Experts. Communities of Experts are specialized groups at Modus that consolidate knowledge, document standards, reduce delivery times for clients, and open up growth opportunities for team members. Learn more about the Modus Community of Experts here.
