Since adopting Agile a few years back, we have been working very hard to get aligned with the practice, in particular Scrum. Weekly study groups sharpen our knowledge, and a number of team members have become certified Scrum Masters and Product Owners.


To fully embrace Scrum we needed to be more disciplined and implement more standardized processes. One of these was the “Definition of Done”.

What is a Definition of Done?

The Definition of Done (DoD) is a "shared understanding of expectations that software must live up to in order to be releasable into production", usually in the form of a checklist.

Importantly, a DoD is also specific to the environment and teams who are working with it, meaning what works for my team at Web Essentials may not work for yours. This blog post outlines what we learnt defining our own "Definition of Done" .

Why Create a Global Definition of Done?

In Scrum one of the characteristics of the development team is that they are self-organizing and have the power to decide on the best practices for their own team, such as how many times the code should be reviewed before being merged into the repository. So at first we gave each team the responsibility of creating their own DoD under the supervision of their certified Scrum Master. But these differing standards created a few issues:

  • Inconsistency for clients - if a team switched halfway through a project, a change in definition could cause confusion for the client
  • Cross team complexity - cross functional team members such as PO, QA and support managers were juggling differing definitions depending which development team they were working with

  • On-boarding obstacles - instead of a universal training session on a global DoD, new staff would have a different understanding depending on which agile team they trained in first.

These inconsistencies soon made us realize we needed to centralize the rules to provide a common framework for all our agile teams to be guided by and ensure that certain steps could not be skipped. Creating an easily accessible and universally applicable DoD became part of the QA department goals for 2016.

How we did it

To create a DoD for the whole company, I brought on board a team of experts from all operation departments, including a QA Manager, IT Manager, Development Manager, Support Manager and the PO Team Lead.

As QA team lead with a good overview across all departments I proposed an initial list of quality requirements to include. This list was pretty long at around 20 in-depth points.

Rather than an overwhelming list of criteria, we wanted our final DoD to be a succinct checklist of the most important conditions; it should be easy for team members to remember and hung up next to their boards for fast reference during daily stand-ups.

Over a period of two months I got the DoD task force around a table every couple of weeks to refine the list and discuss the feedback from each of their teams.

Getting Down to Details

We agreed that the DoD only applies to tasks at the ticket level. Using the logic that all list items should be clear, tangible and easily verifiable, we reduced them down to the most important points i.e. the specific conditions that must be met to move a ticket on the Jira board from 'in testing' to 'done'. If a condition was not specific enough or could not be made any more specific we removed it from the DoD list.

As much of these quality criteria were too valuable to dismiss completely we decided to use them to create two accompanying sets of guidelines:

  1. Release Guidelines: conditions that must be met before the release of an increment to production
  2. Best Practice Guidelines: development best practices that all projects and development teams within the organization are expected to follow

We structured our final Definition of Done in two lists - an 11 point list for the initial developer, and a 10 point list for a QA peer reviewer.


View our example Definition of Done Checklist Download PDF

Then came the time for presentation and roll-out to all departments. We presented our final product to the entire team, as it was important that everyone with a potential client facing role - including HR, Marketing and Sales - knew and started to understand what each point means.

But what about the autonomy of the self-organizing Agile teams?

Although we now had a global acceptance criteria across all projects, the development teams are still self-organizing and should have the power to decide their own best practices.

So we authorized them to add more definitions specifically for their own team. We also made it possible to override or change the global DoD for a specific project, subject to formal agreement from the QA team as resident quality authority. For consistency, these changes must be confirmed before the start of each sprint, not mid-sprint.

Here are a couple of exception examples from previous projects:

DoD Condition   Reason for Exception
Each code change should be tested via continuous integration on our latest system and the client’s staging server before deployment to the live server                 Each code change should be tested via continuous integration on our latest system and the client’s staging server before deployment to the live server
DoD Condition   Reason for Exception
Code must follow standard Web Essentials coding style   Client has their own coding guidelines. In this case, we follow the client coding style instead


How has defining a global DoD improved us as a company?

Now for every sprint, there are one or more QA persons responsible for checking whether the global DoD has been applied to every ticket to a. drive the quality of the work, and b. assess when a user story has been completed. If the DoD is not met it surfaces in the retrospective, demanding accountability for the whole team and motivating team members to consistently apply the conditions to each ticket.

Under a year after implementing our DoD, I can see that defining a set of global company standards has delivered benefits outside the original scope of this exercise.

This includes:

Team - Client Communication

  • An explicit checklist limits risk of misunderstanding between stakeholders about when work is complete on an increment
  • We can present a uniform overview of our quality standards to the client

Increased Product Quality

  • The DoD demands more accountability from the team
  • Product quality is more consistent
  • A global company standard provides a foundation for each team to add new conditions to strive for increasingly higher quality

Internal Clarity & Consistency

  • One global set of company standards is easier for team members to learn and reference, regardless of the team they are currently working in
  • Training of new team members is more efficient

Progress Evaluation

  • Agile methodology should be used to measure and support project progress. Our DoD provides a clear and common framework against which we can drive continuous improvements and track our progress as an Agile company

As Web Essentials develops new products and services, new technologies and regulations demand new quality criteria. Accepting change is key to being Agile so we regularly review the current conditions in the list. This makes our global DoD a living object that grows and evolves with our teams.

If you need a disciplined development team who works to a consistently high quality standard: Talk to us today!

Visay Keo

Visay Keo

Our CEO Visay is an avid technologist with over 15 years experience in software development, web applications, IT infrastructure automation, quality assurance and leadership. He has had many roles within Web Essentials including Senior Developer, Scrum Master, Project Manager, Quality Manager and DevOps Manager. A key skill is his ability to bridge the communication gap between technical and non-technical people.