Definition of Done

The Scrum Guide – 2020

Commitment: Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

This is one of the most intricate parts of the Scrum framework. The definition of Done bears high importance for the entire Scrum Team and for the organization. If the definition of done fails to impose stringent standards, the technical debt will constantly accumulate. Initially, a weak Definition of Done may seem to speed up development. However, in the long run, the opposite is going to happen. The larger the technical debt, the slower the sustainable velocity is. A ‘lenient’ Definition of Done decreases transparency. If the increment is not potentially releasable then hidden work is standing between the product backlog and the product. The difference probably means weeks of work.

To fully understand the importance of the Definition of Done, we have to place ourselves into the seat of the Product Owner. Let’s change our point of view entirely for a paragraph:

As the Product Owner of the Scrum Team, I am accountable for delivering a successful product through managing the Product Backlog. During the last Sprint Planning, the Developers forecasted the delivery of numerous Product Backlog items. They have completed them in this Sprint, the Review went well. So, what is next?

• Can I check the Increment, not just a demo work? Is it in a condition that allows me to determine whether it fits my original ideas?
• If yes, can I make a decision on a release?
• Regardless of a potential release, can I tell my stakeholders we are ready with these items, clearly expressing the status of the implementation process?
• Am I still free to make changes to the Product Backlog without any hidden dependencies, or restraints?
• Can I expect my team in the next Sprint to fully focus on the newly selected backlog items?

If the answer is “no” to any of the questions above, our agility may not be in good shape. Unfortunately, for many teams, the potentially releasable increment is not necessarily achievable. However, as a thumb rule, a Done item must not invoke further days of work before it becomes really done. The Guide very elaborately explains that every team (or synchronized teams) must find their optimum in defining Done and should apply it to every piece of delivered increment.

Who defines the Definition of Done?

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

Thus, the Definition of Done can be defined by the organization and refined by each team to their specific needs. If the organization does not have a Definition of Done, probably still has rules that can serve as directives for individual teams.

When multiple teams work on the same product, they need to mutually define a common Definition of Done which guarantees that the Increment will be potentially releasable. However, in practice, teams can still have different definitions for their work, reflecting their circumstances.

Team members may have different opinions and interests in adding conditions to the definition of done. Ideally, the team can manage dissenting opinions and find a solution that is acceptable for all members and good for the sake of the team. If Scrum values are present, the team should be successful in reaching an agreement. In a less favourable situation, the Scrum Master has to facilitate the decision.

What is typically included in a Definition of Done?

The options are unlimited and should correspond to the environment of the team. Below are some examples that can form part of a Definition of Done:

• Code implemented, and added to the repository; code adheres to coding standards;
• Peer review performed, and all issues resolved;
• Test coverage reaches the threshold, testing is successful, and all issues are resolved;
• Test and build automation implemented, no errors and warnings appear;
• Automated build and testing successful, integration issues resolved;
• Technical specification written, reviewed, and added to the repository;
• User manual and any other documentation updated, added to the repository;
• Integration test performed, errors rectified;
• Security guideline requirements met;
• The Product Owner inspected and approved the implementation;

Non-Functional Requirements (NFR)

Warning: In the Agile terminology “requirement” is not a favoured term. But it does not change the fact that NFR is a term widely used and bears importance in software development, hence it would be unfortunate to drop this topic based on semantic or cultural excuses.

Some of the non-functional requirements belong to the Definition of Done, though not all. When a non-functional requirement is part of a particular Product Backlog Item and does not apply to all increments, it should not be a part of the Definition of Done. In the above example, the generic ‘security guideline requirements’ are applicable to all Product Backlog Items.

Definition of Done versus Acceptance Criteria

There is a widespread misconception that the Definition of Done is either the same or an alternative to the acceptance criteria. This is, of course, not true.

• The Definition of Done is a set of technical and administrative requirements every single Product Backlog Item must meet before the Developers can claim it ‘Done’.
• Acceptance criteria are a specification technique. Usually, several acceptance criteria are added to a Product Backlog Item to enhance clarity and to help the testers evaluate whether the implemented solution reached the intended business goal.

The Catch 22

Releasing new features involves work. Sometimes a huge amount of work. Sometimes a part of the work is to be done in a production system (see Production Verification Testing and Piloting).

What if the Definition of Done includes all these actions? A Product Backlog item is not entirely ‘Done’ until it is productionized. Can we forget the Product Backlog item when it is not yet released just in a usable condition?

There is no ‘as per the book’ solution for this problem, but perhaps it is a pragmatic approach to have a ‘ready-for-release’ and a ‘released’ state of the Definition of Done.

Key Takeaways

• The Definition of Done is typically set by the organization, if not, the Scrum Team must define it.
• If multiple teams are working on the same product, they must mutually define the Definition of Done.
• Acceptance Criteria define the behavior of a single Product Backlog item, the Definition of Done the entire product.

The previous versions of the guide trusted the Scrum Team’s Development Team (now replaced by the Developers) in deciding about the Definition of Done. This was looking more than just a figure of speech, so the current version slightly changed this rule, trusting the entire Scrum Team with the responsibility. This means the Product Owner and the Scrum Master should also have a say. We can argue that it is a more balanced approach since the Product Owner has somewhat different interests than the Developers.