Definition of Done

Basic

difficulty

Stage 2

Agile IQ® Level

1:00h

Timebox

Team Setup

Event

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.

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.

The Definition of Done doesn’t need to include:

  • Showcase the User Story to the Product Owner and get approval (people used to do this around c2000, but rarely do it anymore).

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 Done.
  • Projects.
  • Release management.
  • Getting a specific role/function (e.g. a B.A.) to do specific activities.

THe following only applies to Waterfall.

  • User Acceptance Testing (UAT) – this activity typically becomes superseded in Scrum when Sprint Review is conducted.
  • UAT / BRD 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).

ExampleS of a Definition of Done

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

For a 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.

For a 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.

For a 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.

References

1. Mitchell, I. (2017) Walking through a Definition of Done. Scrum.org

2. Hodgson, M. R. & Horrigan, M. B. (2021) Agile Essentials. 

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