Definition of Done in Scrum Posted on Jan 25, 2017 by Corinna in Agile & Lean, Product Management |

What does it mean when something is “Done”? Especially in software development people’s expectations vary when they hear “Done” significantly. It could mean anything from “finished coding” to “written and tested” to “documented, released and blogged about it”. In Scrum, a dev team and their product owner compare expectations and agree on a shared Definition of Done.

To make it less abstract, I’ve included two examples of real-world DoDs. They are from the same company, five years apart. You might notice that the older one is more inward-looking and the newer one more customer-focused. It is also shorter, e.g. tests are not specifically mentioned. That is not because this team didn’t write tests anymore but because writing tests (and many other things) had become second nature several years before. If at any point the PO and dev team had noticed mismatched expectations about testing, they would have come to an agreement and added it to the DoD.

Neither of these DoDs is better or worse than the other. Each DoD reflects the joint expectations of PO and dev team at that time. They were the ultimate checklist whether they had thought of everything.

The Definition of Done has an unofficial brother, the Definition of Ready. The DoR captures the shared understanding of when a product backlog item is groomed well enough to be worked on in a sprint. I hope to cover it soon.

Did you know there are compilations of our 1-pagers? About Agile & Scrum, Facilitation and for Product Owners

Content of 1-Pager:

Definition of Done

What can you expect when a team declares a piece of work “Done”?

In a Scrum team, the dev team and product owner capture their shared understanding of “Done” in the DoD. Paraphrased from the Scrum Guide:

Each sprint, teams strive to deliver potentially releasable functionality that adheres to their DoD. When a sprint backlog item is described as “Done”, everyone must understand what “Done” means.” The DoD varies significantly between teams and influences how many items a team can take on per sprint. Each increment must be thoroughly tested to ensure that everything works together. As a team matures, we expect it to adapt its DoD to ensure higher quality.

Examples

These are two DoDs from the same company, five years apart. Neither of these is better or worse than the other. Each DoD reflects the joint expectations of PO and dev team at that time. They updated the DoD whenever they discovered gaps.

Team Princess, 2010

– Met all acceptance criteria

– Created sensible language keys in DEV env

– Kept style guide (and updated if need be)

– Followed coding conventions

– User input is validated

– Checked for side effects (e.g. data warehouse)

– Tests run successfully

– Manual tests successful

– Wrote/updated unit tests for touched & new code

– Created/updated Selenium tests

– Frontend works in FF 3.5, IE7, IE8 & Chrome

– Wrote Changelog

– Prepared demo in Test env

Context: Team builds features with customer-facing

web interfaces. The company has just started using

Scrum. They go live every 2 weeks.

Team Planet Express, 2015

– Updated documentation

– Wrote example code in Node & PHP

– LIVE !11!

– Tweeted about it

– If applicable: Answer and close github issues

Context: Team builds an API for a SaaS product. Team

members have been using Scrum for years. They

release features as soon as they’re “done”.

Sources: The Scrum Guide