Definition of Done: The Basics You Need to Know

"What is the progress ...?" I am sure you will agree that's one of the most asked questions by customers or other relevant stakeholders when you are working on a product or service.

But how can you measure the progress of something if you don't know where it ends? It's simple ... you can't.

The same thing applies to knowledge work projects. There, as you rarely know what the final status of a project will be, usually team members start working on things with ambiguous details.

While that's due to the nature of knowledge work itself, it doesn't invalidate the need for some form of consensus that classifies where a work item really "ends". Otherwise, chaos ensues, which brings waste, which kills value.

So, to ensure that doesn't happen, aim to define what "Done" means for your process and the work that flows through it.

What Is the Meaning of the Definition of Done?

To put it in a theoretical manner, the "Definition of done" (DoD) is agreed-upon evidence of completion of a process, activity, or objective. It serves as a guideline with set expectations for a team to meet before completing a work item and delivering it to the end customer. Applying this set of defined criteria in the work process creates consistency and allows team members to separate work currently in progress from the one they finished. 

For example, imagine that you start working on an engineering work item that requires you to prepare the drawings of a new machine part. Unless you have some criteria against which to measure when the item provides value to the next stage of the process, then you might have to do reworks over and over again.

The same holds true for an entire process that delivers some form of product/service to customers (internal or external). For example, if the design engineers work without explicit policies on what it means for products to be fully specified before they're manufactured, the likelihood of defects increases. In turn, this leads to reworks and slows down the entire delivery to the end customer.

Do You Need to Have a Meaningful Definition of Done for Every Work Item?

Our advice is that you do! Starting new work just for the sake of doing something can seriously harm your production of value.

In fact, that's a problem that many managers struggle with. At first look, everyone is very busy with their tasks, but the actual value delivery suffers, leading to unsatisfied customers.

To cope with that, make sure you clearly define your process policies so your team members can understand them. This means creating "Definition of Done" checklists or rules for both your work items and entire processes.   

Regardless of their function, every team needs to come up with their own version of what "done" means to them. It needs to be based on what they intend to accomplish, and it should work in favor of the main goal - ensuring that the final product/ service is completed against the set criteria and that customers receive value every time you deliver.  

Given that work items differ depending on the work type or team assigned, the definition of "Done" might be different for a software engineer developing new features and a marketing person responsible for promoting that same feature. 

Other than that, we should mention that there will always be "necessary waste" in your process. However, the major part of the work you start needs to be connected to your strategic goals, projects, or something else that generates value. Otherwise, it's just unnecessary motion which is a pure waste from a Lean perspective.

Definition of Done Examples 

As mentioned earlier, the Definition of Done varies depending on the project's nature, team preferences, and industry standards. Here are some general examples you can consider: 

Software development team: 

• Code review completed 
• Unit tests passed 
• Integration tests conducted 
• User acceptance testing passed 
• Code documentation updated 

Design team: 

• Design assets delivered 
• Feedback incorporated 
• Prototypes tested with users passed 

Marketing team: 

• Campaign materials approved 
• Content published 
• Performance metrics analyzed

Who Is in Charge of Defining "Done"? 

As with many practices in Agile that require collaborative input, deciding when something is completed and ready to be delivered is no exception. Setting the ground for the answer to “Are we there yet?” should not be isolated but rather a team effort. 

Even though managers mainly define the done-ness of the work, the input from people on the front lines is invaluable. This exercise of agreeing on the checklist of criteria should begin with an open opportunity for everyone involved in the delivery process to contribute by sharing their ideas without hesitation.  

In the end, an environment of transparency is created where the likelihood of mistakes and doubts is reduced because there is a common understanding of what needs to be done. 

Expected Benefits of Defining "Done"

There are many reasons why Agile teams would want to implement DoD into their process. Its importance lies in several key aspects: 

• Clear and consistent process: The DoD provides a clear and consistent understanding of what constitutes a completed work item within the team. This clarity helps avoid misunderstandings and ensures everyone is on the same page. 
• Quality assurance: By outlining specific criteria for completeness, the DoD helps ensure that each deliverable meets the desired quality standards and fulfills user expectations. 
• Minimize risks: Having a well-defined DoD reduces the risk of incomplete or poor deliverables, thereby enhancing project predictability and reducing the need for rework. 
• Enhance team efficiency: When team members understand the criteria for completing tasks, they can focus their efforts more effectively and prioritize activities that contribute to meeting the DoD requirements. 

Common Pitfalls to Avoid 

Despite its importance, defining and adhering to the Definition of Done can pose challenges for Agile teams. Here are some mistakes to avoid: 

• Not bringing clarity in process policies 
• Lack of cross-functional communication 
• Not including critical details in the checklist 
• Adding too many details in the requirement list 
• Not making the DoD list explicit for everyone 
• Rushing to write down the criteria 
• Not involving key figures in the process 
   

How Can You Visualize Your Definition of Done in Practice?

A "definition of done" checklist can be in the form of acceptance criteria that need to be met before your work can move forward.

But how can you make sure everybody on your team understands those criteria and then progressively meets them? A simple but effective way is to visualize them.

In other words, make your process policies explicit, which is one of the main practices in the flow-based management approach. 

In reality, this can be done with the help of a work management board such as the kanban board. There, you can visualize the policies for your entire process as well as specify the definition of done checklists for individual work items (represented by kanban cards).

This is where Businessmap (formerly Kanbanize) can help.

Exit Criteria for Work Items

While a simple way to portray your definition of done is through subtasks or to-do lists, this limits the work information you can visualize. That's why we use special "exit criteria" for our work items.

You can apply them to the kanban columns (representing work stages) in your process. After that, once a given kanban card enters a stage with defined exit criteria, they will be visualized as checklists on the work item. What's handy here is that the system will not let you move a card to the next work stage unless the acceptance criteria for the current one have been met (checked).

This allows us to understand when a given piece of work is truly ready to move forward so we can reduce eventual reworks and ultimately delays.

Note: "Exit criteria" is an exclusive feature in Businessmap. You can read more about it in our dedicated knowledgebase article.

Policies for Workflows and Teams

When it comes down to entire workflows, teams should visualize the policies or rules that define them too. They contribute to releasing a quality product/service to a customer and are an integral part of defining what done means for the whole process.

To visualize those rules, it's good practice to input details about your columns, lanes, or even the entire board. Every single team at Businessmap, for example, has a dedicated place to do that directly from their boards.

Using custom board policies puts everybody on the same page and builds consensus among team members regarding what a "done" product/service really means. This allows us to determine whether we produce value, but it also drives internal discussions of what we could do better.

Note: "Board Policies" is an exclusive feature in Businessmap. You can read more about it in our dedicated knowledgebase article.

Rules for Workflow Stages 

Another useful feature that supports the concept of DoD and its visualization is the “Departure rules”. In essence, Departure rules control whether a card can move out of a specific location in your workflow. By setting up a Departure Rule that requires all tasks within a card to be completed before it can move to the next stage, you can ensure that the Definition of Done is met before progressing to the next phase.  

Using this feature provides a clear visual representation of the progress and when work items are ready for review or deployment in your workflow. 

Note: "Departure Rules" is an exclusive feature in Businessmap. You can read more about it in our dedicated knowledgebase article. 

Definition of Done vs. Acceptance Criteria 

While the Definition of Done and acceptance criteria share a common goal of ensuring quality and completeness, they operate at different stages of the Agile lifecycle. Acceptance criteria outline the specific conditions that a work item has to meet to be considered satisfactory or approved by the customer or product stakeholders. In contrast, the Definition of Done sets the broader standards for when work is ready to be shipped or deployed. 

In Conclusion

When developing a definition of done, you should bear in mind the type of work it relates to. In addition, you must have a checklist of conditions that must be present for an assignment to be considered finished.

If there isn't a meaningful definition of done, think twice before starting a work item. Of course, there is nothing wrong with necessary waste, and we all deal with it.

The point is to keep it in the minority of your work process. Otherwise, you risk wasting time and resources on something that might not be helpful to anyone.