Done

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.

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

Proverbs:

Also Known As:

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.

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: