Digital Delivery

Agile Ways of Working

Agile Defintion of Done

Discussion Document
Digital Delivery Discussion Document

1 Revision History
Date of this revision: 5th June 2013

Revision Summary of Changes Author Changes

date marked

05/06/13 Initial draft Michael Parkinson No

2 Distribution
Consultation distribution list:

 Alex Roth
 Karl Mansour
 Steve Barker
 Femi Hezekiah
 John Cowper
 Mark Vassallo
Digital Delivery Discussion Document

3 Purpose of this document

The purpose of this document is to outline a format for an element of the proposed agile
process.

4 Introduction
Definition of Done - “Complete as mutually agreed to by all parties and conforming to an
organization’s standards, conventions, and guidelines. When something is reported as “done” at
the Daily Scrum or demonstrated as “done” at the Sprint review meeting, it must conform to this
agreed definition.”

Agile Project Management with SCRUM, Ken Schwaber

5 Defining Done

5.1 What happens if you do not define done?

If you do not have an accepted definition of done within the SCRUM framework the following are
likely to occur:

 Increased Technical debts – “Pay me now or pay me later”

 The undone work has a habit of accumulating in a nonlinear manner creating poor
quality deliverables.
 Illusion of progress (velocity) and unpredictable delivery date and scope.
 Team have a tendency to over-commit the amount of work they can do in a sprint
 The product owner doesn’t get what they want and will often “kick off” during the sprint
review session, impacting on team moral, overall productivity and perception of the team
from the outside world.

5.2 Who should define done?

This is a mixture of company policy and team agreement.

In almost all cases there will be a set number of key deliverables defined by the company which
must be adhered to before a given application of function can be considered complete. For
example:

 Coding Quality Standards

 Security requirements
 Version control
Digital Delivery Discussion Document

 Documentation and Service Introduction / Hand over.

Following this it is down to the team to agree and document what their definition of done is.
This should be done before any development work is undertaken and reviewed during each
sprint retrospective. The definition of done should therefore be considered to be an evolutionary
concept within the team and in most cases, bar the company policy implications, be directly
aligned with the team and the nature of the project.

The most important thing is that the defined concept of Done is created in agreement with ALL
team members and is displayed within the SCRUM Stand up area of the office and rigorously
adhered to by everyone both in the team and outside of it.

If it does not meet the Definition of Done criteria then it is not Done.

5.3 Initial thoughts on Done

The following is taken from a number of sources and can be considered a simple starting point:

 Unit tests pass and coverage met standard (85% or above)

 Sufficient negative unit tests were written (more negative than positive)
 Code is reviewed (or Pair programmed)
 Coding standards are met
 Integration testing implemented (automated build, deployment and testing)
 Code has been refactored where necessary based on code review.
 UAT tests pass (test case requirements)
 Non-functional tests pass (scalability, reliability, security, etc.)
 Source code has been placed in the relevant repository.
 Gold Build Deployment Package has been created and is available to the relevant
implementation team.
 Implementation testing in Pre-Production Environment has been completed. (Roll in /
Roll Out all scripts including DB / UI templates / Code)
 Necessary documentation is completed and signed off.