Scrum Pattern Library

The following Pattern is an excerpt from Exploring Scrum: Patterns that Make Scrum Work, which is a work in progress written by Dr. Dan Rawsthorne. Download the latest version on LeanPub.

Pattern: Definition of Done (DoD)

Well-Formed Teams are supposed to have a Standard of Care that they follow, because they are Professionals. Unfortunately, in software, most don’t seem to…


The Scrum Team Members don’t use, or don’t know, an appropriate Standard of Care in their work.


You have a Scrum Team doing work, and the work they are doing is not meeting an appropriate Standard of Care.


Attach a Definition of Done to each Item (augmenting the Item‘s Acceptance Criteria) that assures that the Item is developed with an appropriate Standard of Care. The ScrumMaster works with the Team to assure that the Item meets this Definition of Done as the Item is being worked on.

Discussion, including examples:

Definition of Done DoDWell-Formed Teams are supposed to be Professionals, and come prepared with their own Standard of Care that they do their due diligence to meet every time they do work. The Stakeholders are relying on this when they use a Scrum Team. In software, an example of this is a Development Team that diligently uses the XP Technical Practices and see themselves as Professional Software Craftsmen when they develop their Code.

Often, the Team Members don’t have an appropriate Standard of Care — they’ve never been taught, they’ve never learned, they’ve never used, they’ve never seen such a thing. So, we often have the ScrumMaster (in the role of Technical Coach) help the Team develop, and continuously improve, their own Standard of Care. In the Scrum Community, this is called “having a Definition of Done“. Here is an example of an Item with both Acceptance Criteria and Definition of Done for an Item involving an Airline website.

When there is more than one Team working in the same Codebase, they each should use the same Definition of Done, as they will be working with each others’ Code. Each Team needs to trust the other Teams’ Code as much as they trust their own — they need to know that the other Teams used their due diligence and met the same Definition of Done as they did.

Usually, each Item has its own Definition of Done, but some Teams have applied the concept to the Product Increment, instead. Some Teams have used a common Definition of Done for all Items, others have custom Definitions of Done for each Item. The Team could use different Definitions of Done for different kinds of Items (this is called Storyotyping1. It really doesn’t matter, as long as everybody trusts that the Results are as “good” as they need to be, all the time.

Sometimes the Team can’t meet its Definition of Done, either intentionally or unintentionally. When they do this we say that they have Undone Work. This work may need to be Delivered or Reviewed for perfectly valid business reasons (Trade Show, big Client, whatever), but the Team may not pretend that the Work was Done — the Team Members may not pretend that the Work met an appropriate Standard of Care. When this kind of stuff happens, they need to add a Cleanup Item — one that promises to clean up, or finish the work — to the Backlog, so that nobody will forget it; so that the Team will get the work Done as soon as possible.

The Definition of Done can be extended to be a robust Standard, including standardizing architectural and design patterns, providing necessary reviews and inspections, and so on. It is something worth standardizing, in my opinion, as it provides an anchor for the Teams to Self-Organize around — “this is what we’ve got to make it look like, how do we do that?”

Because not all ScrumMasters are technical, this could lead to a Technical Owner or Coach role on a Team, who would be a Team Member who was Accountable for the existence of, training on, and use of, an appropriate Definition of Done.

If you are interested in learning more about Scrum Patterns, check out this awesome book written by Dr. Dan Rawsthorne called Exploring Scrum: Patterns that Make Scrum Work.

1: See chapter 3.10 of Exploring Scrum: the Fundamentals.