In Scrum each iteration – or Sprint – should yield a valuable increment of quality work. If the work is software, work that meets the quality definition should be able to be released. If the work is an article, the work should be in a ready state to hand over to stakeholders or its readers. Special media work can be published. Everything in a Sprint is designed to lead up to that moment.
An understanding of what makes an increment truly releasable – and therefore genuinely “Done” – provides transparency over the work a team plans to do, and the tasks it brings into progress.
The Definition of Done applies (by default) to all work the team does. When a particular piece of work needed additional quality criteria, or business rules, for it to be potentially releasable, “acceptance criteria” is added to that item.
The Definition of Done should include things like:
The Definition of Done might include things like:
The Definition of Done doesn’t need to include:
The Definition of Done doesn’t apply to:
THe following only applies to Waterfall.
Remember that a Definition of Done properly applies to an increment.
First, check that no unintegrated work in progress has been left in any development or staging environment. Next, check that the continuous integration framework is verified and working, including regression tests and automated code reviews. The build engine ought to be configured to schedule a build on check-in. It may also trigger hourly or nightly builds. Also, check that all of the test data used to validate the features in the release has itself been validated .
All design models and specifications, including user stories and tests, must be in a state that support personnel can maintain it.
Part of the work in a Sprint includes preparing for the review. Sprint metrics ought to be available, including burn-down or burn-up charts. Any user stories which have not been completed should be (a) re-estimated (the remaining work) and (b) returned to the Product Backlog.
Any and all “To Do” annotations must have been resolved, and the source code has been commented to the satisfaction of the team. Source code should have been refactored to make it understandable, maintainable and better able to support future change. Note that the Red-Green-Refactor pattern found in Test Driven Development is helpful here.
Unit test cases must have been designed for all of the features in development, and allow requirements to be traced to the code implementation such as by clear feature-relevant naming conventions. The degree of Code coverage should be known, and should meet or exceed the standard required. The unit test cases should have been executed and the increment proven to work as expected.
Peer reviews ought to be done. If “pair programming” is used, a separate peer review session might not be required.
Source code is checked into the configuration management system with appropriate, peer-reviewed comments added. The source code should have been merged with the main branch and the automatic deployment into elevated environments should be verified.
Functional testing should be done. This includes both automated testing and manual exploratory testing, and a test report should have been generated. All outstanding defects (or incidents such as build issues) should be elicited and resolved, or accepted by the team as not being contra-indicative to release. Regression testing has been completed, and the functionality provided in previous iterations has been shown to still work. Performance, security, and user acceptance testing should have been done, and the product should be shown to work on all required platforms.
The work needs to be digested by others, so ensuring that it’s in plain English and spell checked (US versus UK?), ensures the work doesn’t come back to the team.
Peer reviews ought to be done. If a “pairing” activity has been used, a separate peer review session might not be required.
All the work that went into the document, including support material, should be stored in the corporate file repository.
Creating consistency is important for corporate information. Use the appropriate template and, if you need to change it, then make an alternate version and ensure it’s also available to others.
The work needs to be digested by others, so ensuring that it’s in plain English and spell checked (US versus UK?), ensures the work doesn’t come back to the team.
Peer reviews ought to be done. If a “pairing” activity has been used, a separate peer review session might not be required.
All the work that went into the document, including support material, should be stored in the corporate file repository.
Creating consistency is important for corporate information. Use the appropriate template and, if you need to change it, then make an alternate version and ensure it’s also available to others.
1. Mitchell, I. (2017) Walking through a Definition of Done. Scrum.org
2. Hodgson, M. R. & Horrigan, M. B. (2021) Agile Essentials.
