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.
For a Product Backlog item to be considered as “Done”, both the general Definition of Done and any added acceptance criteria must be met.
When an item is Done, it is considered “potentially releasable”. The choice to release or hand over the item to stakeholders or for use by end-users is the choice of the Product Owner. This makes the Product Owner in ITIL4, the Change Authority.
The Definition of Done should include things like:
The Definition of Done might include things like:
Business and user readiness is a key concern for product management when it comes to deciding when to release. Rather than make individual ‘Change Management’ PBIs, incorporate activities into each PBI so that each of them assess the human aspect of ‘readiness’.
The Definition of Done doesn’t need to include:
The Definition of Done doesn’t apply to:
As the following activities only apply to Waterfall, they aren’t part of an agile team’s Definition of Done:
But we *have* to do UAT!
Many companies find themselves in a “hybrid” agile world. This is a normal stage of progression from ad-hoc operating models to agile product management. For teams currently working in a hybrid Waterfall/Scrum world, it may be useful to have:
Acceptance Criteria is the best place to indicate the hand-offs when work done in a PBI by an agile team then needs some sort of external team QA, sign-off or approval, especially for hybrid Waterfall/Scrum environments.
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.
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.
Ensure that the voice is right and speaks to the target audience in a way that will resonnate with them.
It’s easy to miss something in a communication so it’s important to have another pair of eyes check through spelling, grammar and other quality control mechanisms you have for engagement.
If a “pairing” activity has been used, a separate peer review session might not be required.
Using Hubspot, Eloqua or Customer.io, or some other automation tool? These engagement tools often need updating
All the work that went into the document, including support material, should be stored in the corporate file repository. This might be Asana, Google Drive, a formal document management system, or just the Windows File Share.
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 understood by staff so they can work according to the company’s rules. Ensuring copy is in the native language of staff and is no more complex than high-school reading level (and is spell checked) ensures the work doesn’t come back to the HR team for corrections when there’s missunderstandings.
Improving the staff experience won’t be effective unless it speaks to the target audience in a way that will resonnate with them.
It’s easy to miss something in a communication so it’s important to have another pair of eyes check through spelling, grammar and other quality control mechanisms you have for engagement.
If a “pairing” activity has been used, a separate peer review session might not be required.
Using HRMs like Microsoft Dynamics 365, Float, or Monday.com? These platforms may need updating as a result of HR engagement with individuals.
All the work that went into the document, including support material, should be stored in the corporate file repository. This might be Asana, Google Drive, a formal document management system, or just the Windows File Share.
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.
Download the Definnition of Done Fact Sheet with examples.
1. Mitchell, I. (2017) Walking through a Definition of Done. Scrum.org
2. Hodgson, M. R. & Horrigan, M. B. (2021) Agile Essentials.
All fields are required.
