Definition of Done

Basic

difficulty

Stage 2

Agile IQ® Level

Quality

Practices

Scrum

Framework

Introduction

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.

Done vs Acceptance Criteria

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.

award-medal-1

Definition of Done

  • Unit tests coded and passed
  • Coding standards followed and peer reviewed
  • Code checked in and merged into mainline
  • Performance standards
  • Non-functional requirements met
list-to-do

Acceptance Criteria

  • I can view my payment details
  • I can set up a payment plan using Paypal, Visa or Mastercard
  • I cannot pay with an expired card
  • I cannot pay with an invalid card or Paypal account

Things to watch out for

The Definition of Done should include things like:

  • Test case, scenario, data documentation, results – what ever it takes to make the end result “potentially releasable”.
  • Security standards.
  • Operational standards – uptime, response time.
  • Architectural requirements – scalability, modularity.
  • Usability – WCAG 2.0 AA.
  • Updating user and training manuals.

The Definition of Done might include things like:

  • Delivering training.
  • Communications and change management engagement.

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:

  • Showcase the User Story to the Product Owner and get sign-off. This is an old practice that unfortunately turns the Product Owner into a bottleneck. If the team is self-managing, they should be able to confirm items meet the Definition of Done themselves.

The Definition of Done doesn’t apply to:

  • Features – just the items taken into the Sprint itself. Once the smaller Product Backlog items are “Done”, then the larger Feature is also Done.
  • Projects. A project is considered complete (instead of Done) when its work is sign-off and handed over to the customer.
  • Release management. By default, the DOD ensures everything is of high enough quality to be released. It is the responsibility of the Product Owner to determine when to release value.
  • Getting a specific role/function to do specific activities, e.g., “The BA must update the requirements documentation. The Tester must do functional testing.”.

As the following activities only apply to Waterfall, they aren’t part of an agile team’s Definition of Done:

  • User Acceptance Testing (UAT) – this activity typically becomes superseded in Scrum when Sprint Review is conducted. UAT is a practice in PRINCE2’s project management methology, not part of Scrum or any other agile framework.
  • UAT sign-off.
  • Business Requirements Design sign-off.
  • CAB approval (the PO often becomes the “change authority” in ITIL v4, as the Change Approval Board (CAB) process has been replaced by the change authority).

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:

  • Standard operating proceedures regarding how the team works within its Water-Scrum-Fall environment.
  • Clear governance regarding sign-offs.

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.

Definition of Done Examples

Remember that a Definition of Done properly applies to an increment.

programming-hold-code

Software Team

1. Environments are prepared for release

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 .

2. Handover to support is complete 

All design models and specifications, including user stories and tests, must be in a state that support personnel can maintain it. 

3. Review Ready

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.

4. Code Complete

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.

5. Test Complete

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.

single-man-hierachy

Management Team

1. Plan English

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.

2. Peer reviewed

Peer reviews ought to be done. If a “pairing” activity has been used, a separate peer review session might not be required.

3. Stored in the file drive

All the work that went into the document, including support material, should be stored in the corporate file repository.

4. Corporate templates have been used

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.

database-heart

Data Team

1. Plan English

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.

2. Peer reviewed

Peer reviews ought to be done. If a “pairing” activity has been used, a separate peer review session might not be required.

3. Stored in the file drive

All the work that went into the document, including support material, should be stored in the corporate file repository.

4. Corporate templates have been used

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.

social-profile-bubble

Marketing Team

1. Plan English

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.

2. Spelling, Grammar and Voice

Ensure that the voice is right and speaks to the target audience in a way that will resonnate with them.

3. Copy is peer reviewed

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.

4. Communications calendar has been updated

Using Hubspot, Eloqua or Customer.io, or some other automation tool? These engagement tools often need updating 

5. Stored in the file drive

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.

6. Corporate branding and templates have been used

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.

social-profile-bubble

HR Team

1. Plan English

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.

2. Spelling, Grammar and Voice

Improving the staff experience won’t be effective unless it speaks to the target audience in a way that will resonnate with them.

3. Copy is peer reviewed

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.

4. People’s details need updating

Using HRMs like Microsoft Dynamics 365, Float, or Monday.com? These platforms may need updating as a result of HR engagement with individuals.

5. Stored in the file drive

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.

6. Corporate branding and templates have been used

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.

Downloads

Download the Definnition of Done Fact Sheet with examples.

References

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.

Your user code appears in your user profile. It is a 12-digit key with spaces between each set of four characters.
Your Agile IQ® ID is your 12-digit subscription key.

2.10

agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close