Methodology Bits: Definition of Done
The purpose of this document is to lay down an agreement between the PO and the developers regarding the functional and quality requirements of PBIs in order to add verifiable value to the product and deliver only completed features.
The Definition of done is split into two parts: the first one defines criteria for PBIs that are ready to be merged back to trunk, the second one defines criteria for features that are actually deployed to production. The reason for separating these two is that the deployment might not necessarily take place as soon as the feature is complete, and some steps only make sense in the context of already merged feature branches.Ready to Merge
What does it mean that a PBI is done and is ready be merged back to the trunk? That it…- … has working code in place
- that meets the coding standard, so that maintenance is easier
- that is checked in to a feature branch, so that it is available in a central location
- that can be automatically built by the CI system without errors, so that the builds and the tests run in a centralized environment
- that does not build up technical debt, or lower static analysis metrics, so that the codebase remains readable and maintainable
- that does not lower test coverage, so that refactoring remains safe
- that is refactored, so that it remains easy to read, understand, and modify
- … has code that was accepted on peer review in the form of the pull request
- and any comments or questions raised during the review were answered and acted upon (“won’t fix” status is also acceptable in certain cases), so that any hidden errors or inconsistencies have a chance to be spotted in time
- … has no outstanding work, or any incomplete work is approved by the PO and is tracked as a separate PBI, so that the released feature is not half-done, or the “known issues” are not forgotten
- contains no unintegrated work, or unintegrated work is hidden behind a feature-flag, so that the feature can be released without the end-user stumbling into half-done features
- … is covered by unit tests
- and all unit tests (including both new tests and tests from previous iterations) pass, so that error localization remains easy
- … is covered by automated acceptance tests
- and all acceptance tests (including both new tests and tests from previous iterations) pass, so that validation of acceptance criteria satisfaction remains trivial
- … is covered by regression tests, so that successful integration with existing functions can be easily verified
- … has its necessary configuration added to the build configuration (where applicable), so that the build and execution environment is ready to correctly integrate the code changes
- and has the necessary build/deployment tools in place, so that building and deploying the code changes related to the PBI is trivial
- … has the correct localization in place (where applicable), so that localized UI elements are displayed correctly for the users
- … is documented for the end-user (where applicable), so that users are informed of the feature
- and all documentation is reviewed and accepted
Done
What does it mean that a PBI is done and ready to be deployed to the production environment? That it…- … has code that is merged back to trunk, so that it is part of the production codebase
- and the feature branch is deleted, so that the source control is not polluted with long-defunct branches
- … is manually tested/validated by a tester or another developer
- and any QA issues were reported back to the PO, and are either resolved or tracked for future reference, so that the product does not contain issues, or the “known issues” won’t be forgotten
- and contains no bugs of deal-breaking severity, so that the release does not endanger the production environment
- and has no more outstanding work or any incomplete work is approved by the PO and is tracked as a separate PBI, so that no half-done features are released
- … is accepted by the UX team
- and any UX issues were reported back to the PO, and are either resolved or tracked for future reference, so that the UX remains consistent through the application, and UX issues that are not considered breaking won’t be forgotten
- … is formally accepted by the PO, so that the team has the confirmation that the developed feature meets the acceptance criteria, and delivers the business values stated in the user story
Comments
Post a Comment