Three short stories about the Definition of Done

What does it mean when a card is put into the Done column? Done can mean that the coding  is completed, it can also include that the code has been reviewed, that it includes unit tests and many other things. Teams sometimes create a “Definition of Done” to state exactly what “done” means and this can be a powerful way of improving quality.

A team I worked with that created a “Definition of Done” did so to create a consensus across the engineering teams about what tasks need to be completed on a card before it could be put into the Done column. Team members put forward suggestions on changing the Definition when they felt it was appropriate, and what was included in the Definition was reviewed. This Definition of Done was part of a successful transition to improve quality and release features more quickly. 

I heard about a company where the Definition of Done was negotiated as if it was a legal contract between management and the development teams. Once written the Definition was very difficult to update. The Definition was supposed to help improve quality. The status of the Definition as a type of contract showed the lack of trust that existed. The quality of the team’s software did not improve.

I also heard about a Team Lead whose team created a Definition of Done at a retro type meeting with all members of the team contributing to the discussion on what should be included. The discussion led to an in depth discussion of what needed to be completed before a card could be put into the Done column. This team worked together to deliver good quality new features quickly.

A Definition of Done can help teams deliver good quality software quickly. These stories show that using a Definition of Done can help a team improve quality if the Definition is agreed in a collaborative way and there is trust.

Further reading: Defining What Done Means

Published by Mike Harris

Mike has been working in testing for 20 years and is currently the lone tester for Geckoboard. He has been a Test Lead and has also worked as a part of waterfall, lean and agile teams. He is also Programme Secretary of BCS SIGiST. Mike has a B.Sc.(HONS) from Middlesex University and is an Associate of the University of Hertfordshire. He has set up and led a Testing Community of Practice and been part of a successful agile transition. He is Co-Programme Chair of the British Computer Society’s Specialist Interest Group in Software Testing. He also contributed to the e-book Testing Stories and has had articles published by the Ministry of Testing. Follow Mike on Twitter: @TestAndAnalysis

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: