When Done Means Done - How to Create a Global 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" .

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.

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.

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.

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!