The Definition of Done are items agreed to by the Product Owner (or representative), and the Team, that must be completed before a Work Item can be considered Done.
The Definition of Done is the shield that prevents work from entering production that is not considered ready.
A Work Item is Done when the following criteria has been met:
- Pull Requests Merged
- Code Quality Addressed
- No Known (critical) Bugs
- Work Item Completed
- Test Automation Pass
- Acceptance Tests Pass
- Work is in Production
Getting a Work Item to meet a Definition of Done (DoD) often includes:
- Collaborating with Team members during peer review
- Addressing any code quality concerns: static analysis, cyclomatic complexity
- Writing unit, integration, or end to end test automation
- Second test if no test automation. Second test is having someone other than the developer who worked the Work Item verify that acceptance criteria has been met.
Getting a Bug to meet a Definition of Done (DoD) includes:
- Writing unit, integration or end to end test automation
- Addressing any code quality concerns: static analysis, cyclomatic complexity
- Adding resolution details
- Second test if no test automation. Second test is having someone other than the developer who worked the work item verify that acceptance criteria has been met.
Where appliable, pull requests have been peer reviewed by one, or more, team members. Any concerns or comments have been addressed. Build, and tests, pass.
- Warnings have been addressed
- Unused variables / parameters
- Security vulnerabilities
No new bugs have been identified through either executing test automation, or exploratory testing, related to the change made for the Work Item, whether it impacts the Work Item or not.
If, during the course of implementing the Work Item, the change introduces a breakage for another feature, this Work Item cannot be Done until the bug is resolved.
We don't release new known defects.
The Work Item needs to be updated to include details such as:
- Comments/Discussion/Decisions
- Pull Request Link to the Work Item
- Resolution of the Work Item
All work should be tracked in our work tracking system. If you are working on something we need to make sure that its tracked in the system. If its additional scope, create a Work Item to represent it.
Any test automation needs to be in a passing state. Test automation code should be considered as Production code and meet the same level of discipline and professionalism.
Whenever possible, we should strive to cover Acceptance Criteria through unit, integration or end to end test coverage. This helps in regression testing as we continue to make changes to the product.
Where level of effort to test provides diminishing returns, we can cover that Acceptance Criteria through a manual test case. This test case(s) will need to be defined during the refiniment of the Work Item and included as in the scope of work.
Where possible, the Acceptance Tests, should be covered by a Test Case. Ideally, that Test Case will be automated, but in the case that is not practical, a Manual Test Case should still cover the Work Item.
The Customer generally only realizes value when code is running in Production.
Ideally, work will have been demoed to Stakeholders in a Production envirionment. We don't get partial credit for non-production environments. This helps confirm that we are Done and ready to move on to the next Work Item.
We don't want to context switch away to another Work Item until our active work is in Production.