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.
Are you a budding Product Owner? Check out our compilation "Skills for Successful 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