Definition of Done

What Does the ‘Definition of Done’ Mean?

In the Scrum agile framework, the Definition of Done describes the list of requirements that the team agrees must be met to consider a user story or other backlog item complete. The specific criteria will vary by team, but a typical agile team’s checklist for Definition of Done would include:

  • Coding is complete and has achieved its business and functional requirements.
  • Testing is complete, with either no known defects or defects acceptable for this release.
  • Documentation is complete.
  • The item (user story, feature, etc.) is ready for general availability (GA.)

This definition is used by the entire team to agree on the overall quality and completeness that a finished product must exhibit. This concept differs from acceptance criteria. It is a wide-ranging set of requirements that can apply to all backlog items (for example, quality).

Download the Agile Product Manager's Guide to Building Better Products ➜

What Are the Benefits of the Definition of Done Approach?

There are many reasons a Scrum team would want to implement the Definition of Done approach for their work on product backlog items. Here are a few of the primary benefits.

3 Benefits of Using the Definition of Done Approach.

1 . It helps the team make steady and predictable progress.

When they have a clear, concrete list of criteria, they must meet to consider their work finished, an agile team can more effectively plan their workload. They can estimate completion timeframes. The definition can help them focus on what matters. Thus, they are also less likely to veer off track or find themselves missing deadlines in sprints.

2. It increases the accuracy of estimates for the cross-functional team.

The Definition of Done makes clear what the agile team needs to do to consider a project complete. It helps the team offer more transparency to the rest of the organization. That is, because the team has a shared understanding of what Done and releasable will look like. They are better positioned to give accurate estimates to external stakeholders about when to expect projects to be completed.

3. It helps the team work together more effectively.

When they get together to discuss upcoming work—during sprint planning, for example—a Scrum team with an agreed-upon Definition of Done already has a shared understanding of what each item in the sprint will require. This will make it much easier for the team to assign tasks, work cohesively, and ultimately develop higher-quality products consistently.

 

3 Mistakes Do Agile Teams Make with Definition of Done.

1. Including requirements that are outside the team’s control.

One common mistake agile teams make is to include as requirements approvals from stakeholders outside the product team. If the Definition of Done requires signoff from external parties, then the product team does not have ultimate control over when or if its work is complete.

As Scrum.org explains, this illustrates the difference between shippable and releasable. A team might want to have both. A user story or other product increment would qualify as shippable when the product team has completed all of its agreed-upon tasks relating to that item. But at this stage, the item will still need to go through the approval process with additional stakeholders. The team might even describe this phase as its Definition of Almost Done.

When those stakeholders have signed off, then the team will consider the user story or other item releasable. This would be their Definition of Done.

2. Putting too much detail into the requirements list.

Another common mistake agile teams make here is to draft highly detailed list criteria for getting its backlog items to a Done state. Including too many requirements, and too much granularity, can slow the team’s progress and create confusion and disagreement about when an item is truly Done.

An effective Definition of Done should describe only the minimum steps required to move a standard user story or another backlog item from in-progress to complete. To make this process effective and repeatable, the team should keep its list of requirements high-level. The place to include a granular set of requirements for a given project is a team’s acceptance criteria, which detail the specific requirements needed for an individual piece of work.

Note: The team’s Definition of Done can evolve with time and include more requirements as the team becomes more skilled and cohesive. But when they develop their first list of requirements, the team should follow this minimal approach and include only those criteria that will help them move a product item to Done.

3. Relying only on a verbal list of requirements.

For the Definition of Done approach to be effective, the agile team must make its list of requirements explicit. Ideally, keep the list posted in a prominent place where the team can review it every day.

As Agile Alliance explains, if the team has only a verbal agreement about what it means to complete a task, then the team’s Definition of Done can lose a lot of its effectiveness. A significant portion of the value of this approach depends on it being a written team agreement defining the criteria needed to consider a project complete. The team should also be able to see those criteria regularly.

Related Terms

Scrum Agile Framework /Acceptance CriteriaDefinition of ReadyBacklog /General Availability (GA)

Talk to an Expert

Schedule a few minutes with us to share more about your product roadmapping goals and we'll tailor a demo to show you how easy it is to build strategic roadmaps, align behind customer needs, prioritize, and measure success.

Book a ConsultationView Demo