Definition of Done (DoD)

The Definition of Done (or “DoD”) is by far the most powerful item in Scrum… The DoD tells us when we’re actually “DONE!” with a task or issue. Done means that there’s no more work left in the task and it’s cleared from the sprint backlog.

A good DoD makes it easier for the team to agree with the Product Owner and the Stakeholders as to when a task is done (meeting all the acceptance criterias). It’s common known that in traditional workflows a tasks will continue to live on from “sprint to sprint” because something was either forgotten in the description or in the actual resolution of the task. Such tasks are expensive to have in the sprints and multiple issues like this could cause the sprint to fail entirely because the amount of “unknown work” will make it hard to estimate and commit to the sprint.

The DoD is a list of sorts that includes the product owner’s and team’s criteria for declaring a product backlog item as potentially shippable, or done. It’s important for several reasons.

  • It sets a common understanding throughout the organization on what “done” means
  • It is a communication tool for stakeholders
  • It helps remove technical debt

A DoD will contain all the things that eventually should be done before the task can be signed of by the QA and released to production. Examples of items in a DoD could be (but definitely not limited to):

  • All new code should be documented
  • All new code should be commited to versiontracker (GIT/SVN)
  • All new code should pass the build process on build server
  • All new code should have unit tests
  • All browser tests should be completed
  • All automation tests should be completed

The amount of items in the DoD would vary from team to team. Also, it’s very important not to put items in the DoD that is impossible to obtain. If that happens the DoD will be loosing its effect and the team will eventually ignore it.

The team must see the DoD as a tool to state when the issue is Done. It’s a tool to ensure that code quality and test coverage is in place. It’s a guardian of the development process and therefore something that they should enforce and extend over time.