What is Definition of Ready (DoR)?
This is a checklist used as a reference against each task before starting the work to ensure the task/work item meets a minimum entry criterion. Meeting the checkpoints ensures all the inputs are available, expectations are aligned & probability of task completion as per the acceptance criteria would be higher. One example is added below for a Definition of Ready checklist recently recommended for a DAO sub group, where we track the project tasks on a notion Kanban board.
The purpose of the definition of ready is to provide a clear, objective measure of what needs to be done before work can begin on a project or work item. This helps to ensure that the project team has a shared understanding of what needs to be done and that everyone is working towards the same goals.
Having a clear definition of ready also helps to prevent waste and inefficiency in the project development process. By ensuring that all necessary work is completed and all necessary information is gathered before work begins, the definition of ready helps to avoid situations where work is started on a project or work item only to discover later that important information is missing or that key decisions have not been made.
DOR Checkpoints:
Is the task aligned with the season’s objectives for the guild?
Are all the required fields in the task updated for complete information?
Are the Deliverables detailed in a self-explanatory way to assist async working?
Review process & acceptance criteria is aligned and available?
Is the task time boxed to have an expected completion date?
What is Definition of Done (DoD)?
This is a checklist used as a reference against each task to successfully mark a task/work item as Done. Meeting the checkpoints ensures quality, review and rework completion and structured handover. It helps by acting as a stage gate between WIP items and done.
Having a clear definition of done also helps to prevent scope creep, which is a common problem in software development. Scope creep occurs when new requirements or changes are introduced to a project without properly accounting for. It also helps to improve the quality of the project deliverables. By setting clear criteria for what constitutes a completed project or work item, the definition of done ensures that all work is completed to a high standard and meets the needs of the customer or end user.
It also aligns everyone in the team to have a common meaning of what ‘done’ means especially during status update meetings and project reporting. Example of Definition of Done is shown below.
DoD Checkpoints:
Did the task meet all the deliverables listed?
Deliverables are presented in a team meeting or shared async to the team for review and feedback?
Review process & acceptance criteria is adhered to and the comments if any are incorporated/rejected?
Deliverables are shared in the repositories with any associated documentation for continuity?
Any lessons learned are captured and shared for continuous improvements and team records?
Above DoR and DoD checkpoints in a template format can be downloaded from here. The definition of ready and definition of done are more prominent in a web3 projects where team members work async as they help having a common agreement on when an item can be started to work on and when an item would be considered done.
“The Definition of Done (DoD) applies to all user stories being developed by the team. In contrast, Acceptance Criteria are specified per User Story in accordance with the Definition of Ready (DoR). DoR, Acceptance Criteria and DoD together ensure that quality is built-in. ”
DoR and DoD For a Scrum Team
the Definition of Ready (DOR) and Definition of Done (DOD) are essential checklists in Agile and Scrum methodologies, ensuring that tasks and user stories are adequately prepared for development and meet all necessary criteria upon completion. Below are standard industry checkpoints for both DOR and DOD that software Scrum teams can refer to and adapt according to their specific project needs.
Definition of Ready (DOR) Checklist
User Story Clarity: The user story is clearly written and follows the “As a [user], I want [need] so that [benefit]” format.
Acceptance Criteria Specified: Each user story has defined acceptance criteria that describe the conditions to be met for the story to be accepted.
Dependencies Identified: All dependencies and constraints related to the story are identified and resolved or planned for.
Size and Complexity Assessed: The story is appropriately sized for the Sprint and is not too complex; ideally it should be deliverable within a single Sprint.
Resource Availability: Necessary resources (personnel, technology, information) are available to work on the story.
Stakeholder Agreement: There is a consensus among stakeholders (product owner, Scrum team, etc.) on the story's priority and value.
No Blocking Issues: There are no external blockers that prevent the story from being worked on.
Design and Technical Feasibility: Preliminary design and technical feasibility have been assessed.
Refined by the Team: The story has been discussed and refined by the team, ensuring a shared understanding.
Definition of Done (DOD) Checklist
Code Complete: The code for the user story is fully written and adheres to coding standards.
Code Reviewed: The code has been peer-reviewed, and any identified issues have been addressed.
All Tests Passed: Unit tests, integration tests, and other relevant tests have been passed.
Documentation Updated: Necessary documentation (technical, user guides, etc.) is updated or created.
Performance Criteria Met: The code meets performance benchmarks or criteria set for response time, load, etc.
Security Compliance: The code has been checked for security vulnerabilities and complies with security standards.
Product Owner Approval: The product owner has reviewed and approved the user story or feature.
User Acceptance Testing (UAT): The feature has passed user acceptance testing, verifying that user requirements are met.
Deployable State: The feature is in a deployable state, even if not yet deployed to production.
These checklists provide a structured framework for Scrum teams to ensure readiness for development and completeness of work. However, they should be adapted to fit the context, complexity, and specific requirements of each project and organization.
To summarize, Definition of Ready represents the level of adequacy of the requirements (for development and testing) as specified in the high priority stories in the Product Backlog that the Product Owner want to give to the Development Team during Sprint Planning. Definition of Done represents the Release-Readiness (completion of Development, Testing, and other Acceptance Criteria) of Sprint Backlog Stories at the end of the Sprint. Developers decides if a story is ready to be taken into a sprint and PO decides if a story can be considered as done.
References
Definition of Ready (DoR) and Definition Done (DoD) in Scrum – Lean Agile Council (The home of the Agilitizer). (n.d.). Retrieved October 21, 2022, from https://www.leanagilecouncil.org/definition-of-ready-dor-and-definition-done-dod-in-scrum/
DoD and DoR: A Disciplined Viewpoint. (n.d.). Retrieved from https://www.projectmanagement.com/blog-post/68604/dod-and-dor--a-disciplined-viewpoint
Home | Scrum Guides. (n.d.). Retrieved from scrumguides.org website: https://scrumguides.org/
What’s the Difference between DoR, DoD and Acceptance Criteria? – Sensible Agility. (n.d.). Retrieved October 21, 2022, from https://sensibleagility.com/2020/12/14/whats-the-difference-between-dor-dod-and-acceptance-criteria/
