Agile Glossary

Definition of Done

What is Definition of Done?

The team agrees on, and displays prominently somewhere in the team room, a list of criteria that must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.

Also Known As

Software developers have a reputation for being somewhat careless when answering the question “are you done with this feature”? In fairness, this is an ambiguous question – it can mean “done programming” and this is generally what a developer will have in mind when answering. However, the meaning of interest is usually “are you done programming, creating test data, actually testing, ensuring it’s deployable, documenting…”.

Proverbially, to get an answer to that, the question to ask is, “I know that you are done, but are you DONE-done?”. See also “READY-ready“.

Some teams use the term “Done List” or “Done Checklist”; the less widespread term “product sashimi” offers a compelling image of well-defined slices of a product.

Expected Benefits

  • the Definition of Done provides a checklist that usefully guides pre-implementation activities: discussion, estimation, design
  • the Definition of Done limits the cost of rework once a feature has been accepted as “done”
  • having an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer or product owner

Common Pitfalls

  • obsessing over the list of criteria can be counter-productive; the list needs to define the minimum work generally required to get a product increment to the “done” state
  • individual features or user stories may have specific “done” criteria in addition to the ones that apply to work in general
  • if the definition of done is merely a shared understanding, rather than spelled out and displayed on a wall, it may lose much of its effectiveness; a good part of its value lies in being an explicit contract known to all members of the team

Origins

  • 2002: an early article by Bill Wake calls attention to the possible inconsistencies arising from terms commonly used within teams, such as “done”
  • 2003: early Scrum training materials hint at the future importance of the “Definition of Done”, initially only in the form of a slide title: “The story of Done”
  • 2005: the first exercises inviting Scrum trainees to reflect on their (local) “definition of done” appear in later iterations of Scrum training materials
  • 2007: by that point the “Definition of Done” as a full-fledged practice, and as a textual checklist displayed in the team room, has become widespread

Signs of Use

  • upon request, the team can point to its explicit Definition of Done
  • the team actually uses the Definition of Done at the end of a sprint to justify the decision to count work towards velocity or not
Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

IMPORTANT: We have transitioned to a new membership platform. If you have not already done so, you will need to set up an account on the new platform to establish your user profile.

When you see the login screen, choose “Set up Account” and follow the prompts to create your new account. You can choose to log in using your social credentials for either Google or Linkedin (recommended), or you can set up your account using an email address.

Not yet a member? Sign up now