Over a million developers have joined DZone.

Pattern of the Month: Done (and Every Stakeholder Is Happy)

DZone's Guide to

Pattern of the Month: Done (and Every Stakeholder Is Happy)

The Pattern of the Month at agilepatterns.org looks at the definition of "Done," which always has a vigorous debate around it.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

The idea of work meeting a “Definition of Done” is commonly met in agile practice. The importance of team members having a shared understanding of that definition is obvious if their work is to achieve a known quality and be fit for purpose. However, there is no conformity regarding how, or to what, the term is applied. Is it the increments that are released which must meet the “Definition of Done”, or is it each item of work in progress, such as a user story? Might it be something else entirely?

For example, In Lean-Kanban operations, which can be founded on the continuous integration and deployment of work, it might be reasonable to expect individual backlog items to be completed as per a "Done" assertion of quality. Scrum on the other hand puts the emphasis not on individual items, which constitute a forecast of work, but rather on delivering a "Done" Increment that meets a Sprint Goal. The Scrum Guide, which is the definitive specification of the framework, says: 'At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”'

Even so, the Scrum Guide openly acknowledges that the term "Done" can be applied to individual items of work, and it expressly warns of the need for clarity whenever the term “Done” is used. As such there can be different levels of “Done”, and it can be reasonable to talk about user stories (for example) as being “Done”...although in the case of user stories the term "acceptance criteria” might be used to avoid confusion.

A "Definition of Done" can prescribe many levels of Done, and having multiple levels can be good practice. They can be a good waste limitation strategy for catching and addressing quality issues prior to the integration of work into an increment. However the “Definition of Done" itself might specifically apply to that increment as a whole, no matter how many levels of “done” it encompasses, in order to assert that the integrated work is in fact fit for release.

“Done” is Pattern of the Month at agilepatterns.org


Image title

Intent: Ensure all work is completed to a known standard, so misunderstanding is avoided and rework minimized


  • A stitch in time saves nine

  • If a job is worth doing it is worth doing well

  • The knot tied by a wise man cannot be undone by a fool

Also Known As:

  • Definition of Done

  • Tolerances

Motivation: The state of a product’s completeness can be a source of misunderstanding between stakeholders. For example, work that has been developed but not integration tested may be considered to be complete (“done”) by a delivery team. An end customer, however, may expect that a completed deliverable has also been integration tested. They may also have expectations regarding documentation and end-user training that the development team do not satisfy. Similar discrepancies in understanding can also cause problems within delivery teams. If one developer holds to a different standard of completion than another, then the team will not be able to assert the quality of its deliverables.

Structure: Each backlog item is correlated to general terms of acceptance that apply to all. The development team will accept a backlog item, action it, and test it for compliance with each of those enumerated terms before asserting it to be complete.

Applicability: The Done pattern can be used whenever a workflow item is transitioned between states. It is most important to define Done at the point where an item is considered to be fit for release. The pattern can however be applied at any station in a workflow. For example, a requirement might need to meet user story INVEST criteria before it can be accepted into a Sprint Backlog.

Consequences: A consistent understanding of “done” helps ascertain a deliverable’s fitness for purpose. Inconsistencies in understanding can be expected to lead to confusion, rework, or the unmanaged accumulation of technical debt.

Implementation: A consistent understanding of what “done” means is most often encapsulated within a team’s “Definition of Done”. In Scrum, this definition may be revised during a Sprint Retrospective. “Definition of Ready” is another common implementation of this pattern, where conformance indicates that a backlog item is sufficiently well defined to be actioned by a team. Some development teams use the terminology “Developer Done” to indicate that they have taken their work as far as possible, and “Done-Done” to mean that work is fit for potential release. For example, “Developer Done” may include unit testing, but not quality assurance testing. However, this usage suggests that the team do not wholly own their process, and that the silo anti-pattern might be in evidence.

See Also:

Discover what Scrum Teams do to make themselves great, brought to you in partnership with Scrum.org.

agile patterns ,scrum (development) ,kanban ,quality

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}