Define DoR and DoD
timfoote opened this issue · comments
A Definition of Ready (DoR) is a set of standards that must be met before a product backlog item can be considered for development.
The Definition of Done (DoD) outlines the minimum acceptable criteria that must be met for a feature or task to be considered complete.
User Story
As a Product Owner, I want to define the Definition of Ready (DoR) and Definition of Done (DoD) for my product backlog items, so that the development team has clear guidelines and criteria to evaluate the completeness and quality of each item before it is considered ready for the next stage of development.
Acceptance Criteria
1. The DoR and DoD criteria have been clearly outlined and agreed upon by all stakeholders
2. The criteria includes relevant checks such as requirements, design, testing, documentation, and approvals
3. The criteria are flexible and can be updated as needed to align with the evolving needs of the product and development team
4. The criteria are consistently applied to all product backlog items to ensure consistency and fairness in the development process.
Example DoR:
Clear and well-defined requirements: The product backlog item should have a clear understanding of what needs to be delivered.
Prioritization: The item should have a clear priority within the overall project backlog and have been discussed and agreed upon by the relevant stakeholders.
Dependencies: Any dependencies on other items or external factors should be identified and understood.
Acceptance Criteria: The acceptance criteria for the item should be clearly defined and agreed upon.
Estimation: A rough estimate of the effort required to complete the item should be available.
Risks: Any potential risks associated with the item should be identified and documented.
Stakeholders: The stakeholders involved in the item should be identified and involved in the discussion of the DoR.
Example DoD:
Functionality: The feature should meet all functional requirements as described in the user story and any additional documentation.
Quality: The code should be well-designed, maintainable, and free of known defects. This includes adhering to coding standards and having appropriate tests in place.
Documentation: All relevant documentation, such as code comments, should be updated and any new documentation required for the feature should be created.
User Acceptance: The feature should be validated by stakeholders and any necessary changes should be made based on their feedback.
Deployment: The feature should be deployed to a test environment and confirmed to be working as expected.
Integration: The feature should be integrated with the rest of the system and any necessary updates to other parts of the codebase should be made.
Performance: The feature should meet performance and scalability requirements.
Security: The feature should meet security requirements and any vulnerabilities should be addressed.
First glance these look great. Looking forward to more comments
Might be worth breaking out Acceptance Criteria to also include steps to validate or test. Something people tend to write the acceptance criteria from the users perspective and leave out the acceptance criteria of making sure it's well integrated and tested.
For DoD - I'd consider adding something explicit around monitoring/alerting and HA. Might go into DoR as well. Becomes more crucial in a microservice environment to make sure:
- We know when the thing we just built dies we will get notified
- We know when something the thing we just built is trying to interact with is not available and doesn't cause the system to fall over completely.
Both these points are probably shades of the listed DoR and DoD, but I've found with these specific topics that it's better to be upfront and explicit about it.
@timfoote I love these, great to establish them at the onset.