Even when we’re working towards the same goal, defining when that goal is complete can be difficult. Every member of a team might have their own Definition of Done (DOD).
For example, at a restaurant, a line cook may consider an order done when the food is prepared and awaiting pick up. A server may not call that order done until the food is served. The front of the house may not consider that work done until the customer has eaten, paid, and left the restaurant.
So, who’s right? When is an order done?
Everyone is right to an extent. The line cook finished their work. The server finished their work.
But the end user determines if a task is done. In this example, the end user is the customer. Say they want their steak to be medium-rare. The steak shows up uncooked. The customer will send the steak to be cooked more.
The order isn’t done if the customer doesn’t accept it.
How to Define Done?
The Definition of Done is relatively straight forward:
The team agrees on, and clearly posts, a list of criteria which must be met before a product increment–often a user story–is considered “done”. If that criteria for done is not met by the end of a sprint, the task isn’t considered finished.
Agile methodologies like Scrum state that it’s important for members of a team to share a clear definition of when an increment, like a feature or story, is considered finished. A Definition of Done provides team members clarity, accountability, and a clear metric for classifying increments.
A Definition of Done also provides quality assurance. Requirements need to be satisfied. And those requirements need to be defined and agreed upon up front. When the product or service is complete, or while it is being provided, we can manage and assure quality.
Only when an increment has been tested and meets the criteria is it considered done.
A product increment that isn’t done at the end of a sprint doesn’t count towards a team’s velocity.
The Role of the Product Owner in a Definition of Done
The product owner is responsible for defining the requirements for done. In the absence of that, there should be standards, defined either by an external third party or perhaps within the organization itself.
The developers may document the requirements, like a server writing down how the customer wants their steak or salmon. But the customer defines the temperature of that steak or salmon.
How to Tell Tell if a Team Uses a Definition of Done?
There are a few ways to tell if a team is using a Definition of Done:
If someone asks a team what their Definition of Done is, they should be able to explain what criteria a feature must meet in order to be considered done. If the team can’t answer that, it means they do not have a Definition of Done.
We should also see the Definition of Done posted somewhere in a team room. Without a clear, written Definition of Done, that definition runs the risk of being ignored or changed throughout a sprint or over the course of multiple sprints.
There’s one other way to see if a team is following their Definition of Done. The team should be talking about the Definition of Done during a sprint retrospective. An Agile team will use the Definition of Done to evaluate whether a finished feature meets the conditions necessary to be considered done and count towards that team’s velocity.
