Definition of Done

It’s hard to declare that a task is complete if no one can agree on what “complete” means. A product development team without a specific target to accomplish might be continuously asked to expand its scope. This can cause bloat and bogging down development. Conversely, a product team might ship a product with missing features, just to meet a deadline. This is why projects need a Definition of Done, to serve as a lighthouse that guides product teams towards the finish line.

In this glossary article, we discuss the Definition of Done, why it’s so important to have in every project, and how to establish one with your team.

What is the Definition of Done?

Simply put, the Definition of Done is a checklist of conditions or action items that teams must complete before a project is considered complete. All stakeholders must agree upon it to represent a final state, so that no one can then put in a further request for additional work. Once a task is done, it’s time to move forward to the next goal.

It’s very important for all project stakeholders to have the same understanding of the Definition of Done. Agile teams, product owners, management, and clients must all be able to agree that a project is complete. Otherwise, they risk scope creep or delivering projects that don’t meet requirements. Having clear definitions also promotes transparency across the team and with clients.

Examples of definitions of done include:

• Documentation has been written for code
• Code has been OKed by QA teams
• Code has passed user acceptance testing

Keep in mind that there is a difference between the Definition of Done and acceptance criteria. While everyone decides on the Definition of Done right before a sprint begins, it applies to all user stories. Meanwhile, acceptance criteria only apply to their respective user stories, and you can actually decide on them during development.

Who Creates the Definition of Done?

In most cases, the software development company provides the bulk of the work when it comes to creating the Definition of Done. This is because they have the best understanding of what a project needs to function and perform well. Usually, the specific stakeholder who decides the definitions is the scrum master, CTO, or other technology leadership role.

However, while engineering decides on the creation of the definitions, it must still have input from the product owner, QA teams, and other groups involved in the project. Any Definition of Done must have recognition and approval from all of its stakeholders to be effective.

How Do You Decide On the Definition of Done?

What makes a good Definition of Done? These practices can help you create a clear, actionable Definition of Done that your team will accept.

1. Don’t Micromanage Your Ideal Definition of Done With Too Many Criteria.

Having too many criteria in a Definition of Done is definitely a headache for any stakeholder. And having to keep track of numerous conditions for doneness creates an even more administrative workload. They’ll then try to manage by either skipping a few checklist items or doing everything at once—poorly.

Instead, try to create definitions that give agency to your teams to approach a certain quality level, using the minimum effort required. 

Besides that, the definitions will change as you go through the development process. Spending too much time on a perfectionist set of criteria, only to change them later on, may be a waste of your time. 

2. Ensure That Stakeholders Participate in the Definition.

A software project is an intricate machine composed of many moving parts, each with a unique purpose. Similarly, every stakeholder has something meaningful to contribute in their own way. By working on your Definition of Done, you get input from all stakeholders from all angles, such as documentation, design, QA, and timelines. 

Besides that, having all stakeholders participate promotes transparency in the team. Every stakeholder gets to understand why the Definition of Done is designed that way, as well as what work is required to achieve that completeness.

3. Always Remember Business Objectives.

Because engineering teams heavily manage the Definition of Done, occasionally, this definition may lose sight of strategic business goals. It’s important to involve strategic management to make sure that it’s aligned with business objectives.

The Benefits of Having a Definition of Done

A clear Definition of Done has several benefits for product development, including:

1. It Removes Ambiguity About Doneness.

Without a clear Definition of Done, stakeholders may end up arguing about what constitutes “doneness” for a feature, sprint, or project. This creates conflict and wastes valuable time between tasks. A good Definition of Done allows everyone to refer to a checklist and address any points of confusion before they have a chance to snowball.

2. It Reduces Rework.

Once a team member or manager considers an item “done” based on a strong definition, there is little need to revisit it to check up on or finish incomplete tasks. Every “done” task will have the appropriate documentation, reviews, and approval. One of the great benefits of this is that it also helps reduce the amount of unintentional technical debt that your product accumulates.

3. It Introduces Accountability.

The Definition of Done clearly defines which parts of each project are whose responsibility. Because every task goes through a checklist of doneness criteria that are unique to each team, QA checkers can trace all conditions back to someone’s oversight or mistake.

It Isn’t Over Until It’s Done

The Definition of Done is a powerful tool for ensuring that each task has achieved a minimum level of quality and refinement before teams move forward. Make sure that you have clearly agreed-upon definitions at all times across the board for your product development process.