a·gen·tic a·gil·i·ty class·i·fic·at·ion

Definition of Done (DoD): Setting Clear Standards for Releasable Quality

Establishing clear, measurable criteria for completed work to ensure transparency, quality, and readiness for real-world use.

Getting Started with the Definition of Done (DoD). Every team should define what is required, what criteria must be met, for a product increment to be considered releasable.

Image
https://nkdagility.com/resources/definition-of-done/
Subscribe

Overview

Every team should define what is required, what criteria must be met, for a product increment to be considered releasable. A definition of done . If the organization has not articulated a specific standard, or set of criteria, then the team should create a definition of done that is appropriate for the product. The work produced must comply with the definition of done for it to be considered usable, and if there are multiple teams working on a single product, then those teams must agree on a definition of done and ensure that all teams honour that standard. {: .lead}

Developers needs to decide what Done means within the organisational context and the product domain. They need to sit down and create a list of things that must be true for every Increment of software that they deliver. Working Software is not specific to a PBI; it’s applied regardless of PBI to the entire delivery.

Definition of Done

“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of > > Done, it cannot be released or even presented at the Sprint Review . Instead, it returns to the Product Backlog for future consideration.”\ – The 2020 Scrum Guide

If you can’t ship working software at least every 30 days then by its very definition, you are not yet doing Scrum . Since Professional Scrum Teams build software that works , stop, create a working increment of software that meets your definition of done (DoD), and then start Sprinting, and review what you mean by “working” continuously, and at least on a regular cadence.

The purpose of the definition of done is to provide transparency of what has been done! This provides the team with focus on whats needed and commitment to the minimum level of quality needed. Every team has full control over the level of quality that they provide.

A clear shared definition of done allows us to:

  1. Maintain Transparency of what we have Done
  2. Understand how much work is required to deliver an item
  3. Create an agreement of what we show at the Sprint Review
  4. Protect our Brand!

Live and in production, collecting telemetry supporting or diminishing the starting hypothesis.\ –from Definition of Done (DoD) for the Azure DevOps Product Teams {: .blockquote}

What is Done?

Done does not reflect the requirements, value, or stories. It is a shared understanding of quality.

If you were creating a definition of done for a bakery that would make a number of products you would likely like the following to always be true:

  1. Kitchen is clean at time of preparation
  2. All ingredients are fresh
  3. All items cooked to the appropriate temperature.
  4. Each batch taste tested

This short measurable checklist that reflects quality should be true regardless of what the bakery is creating; baguettes, donuts, or meat pies. All must meet this simple definition of done to be sellable and not risk the customers, its employees, or the business.

Before you cut a single line of code, you need to decide what done means for your product and your company. It will be defined very differently if you are building firmware for pacemakers or if you are creating an e-commerce portal. Here are some characteristics of a Definition of Done:

A simple definition of DOD from Scrum: “a shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Scrum Team .”

Your short, measurable checklist that mirrors usable and results in no further work required to ship your product needs to be defined. A great way to do this is to get the Scrum Team (the Product Owner plus the Developers and any relevant Stakeholders) into a facilitated DoD Workshop . Without a Definition of Done we don’t understand what working software means, and without working software we cant have predictable delivery. Your Product Owner can’t reject a Backlog Item, only whether the Increment is working or not.

No mater what you are building you should have a clear and concise definition of done that can be understood and articulated by the whole Team, and ideally by your stakeholders.

Done Means Releasable

When the Product Backlog item or an Increment is described as Done, everyone must understand what that means. Although this varies significantly per team, members must have a shared understanding of what it means for work to be complete to ensure transparency, the foundation of any empirical system. This is the definition of done for the team and is used to assess when work is complete on the product increment. The same definition guides the developers in knowing how many Product Backlog items they can select during Sprint Planning . The purpose of each Sprint is to deliver Increments of releasable functionality that adhere to the team’s current definition of done.

An explicit and concrete definition of done may seem small, but it can be the most critical checkpoint of work. Without a consistent meaning of “Done”, we cant know what it takes to get something finished. Conversely, a common definition of done ensures that the increment produced at the end of iteration is of high quality, with minimal defects. The Definition of Done is the soul of Scrum, and mature Developers will resist demonstrating at the Sprint Review (let alone deploying) any increment that is not Done.

Releasable

A releasable product is one that has been designed, developed and tested and is therefore ready for distribution to anyone in the organisation for review or even to any external stakeholder. This isn’t a prototype or a demo-only release. This is ready for production. Adhering to a list of acceptance criteria ensures that the Increment is truly releasable, meaning:

The Product Owner can accept the work at any time during the Sprint. The Sprint Review should not be an “acceptance meeting”, but rather an opportunity to inspect the Increment and adapt the Product Backlog.

My First Definition of Done (DoD)

Your Definition of Done does not just magically appear, and your software does not magically comply with it once it has been created. Making your Software comply with your definition of done is hard work, and while your definition of done should organically grow, you need to create the seed that you can build on.

I recommend that you run a DoD Workshop with the entire Scrum Team, and likely some other domain experts or interested parties. If there are stage gates that your software has to pass after Developers are Done, then you need representatives from those gates to participate in the workshop. Regardless of your product you likely need representatives with the following expertise; Code, Test, Security, UX, UI, Architecture, etc. You may have this expertise on your team, or you may need to bring in an expert from your organisation, or even external to your organisation.

Here is a list of things that you should consider for your DoD:

Ultimately ask your self: “Would you be happy to release this increment to production and support it? You are on call tonight!”.

Whatever Definition of Done you come up with it is unlikely that your entire Product currently meets the criteria. You are not yet doing Scrum. Before you start Sprinting, you need to focus on making sure that your current Increment meets your new Definition of Done. Focus on Quality, which is what the Developers are accountable for, and make sure that your Increment meets that new quality bar before you start. The next Increment can only reach the quality bar of all those that came before do.

The Definition of Done is the commitment to quality for the Increment!

Create a usable increment that meets your definition of done and then start sprinting. Keeping your software in a working state will require a modern source control system that provides you with the facility to implement good DevOps practices.

A Starting Point for any Team

Some examples of things for a software team to put on their definition of done:

There are 4 key layers to your DOD that you should consider:

  1. Meets organizational DOD - what is minimum quality level required by your organization to protect its brand and reputation.
  2. Meets Practice DOD - Your practice may add additional elements to DONE based on the technical domain within which you are working.
  3. Meets Customer DOD - Additional quality standards required by the customer.
  4. Your Teams DOD - Run a DOD workshop to identify what you need from 1,2, & 3 as well as anything that your Scrum Team feels that they need to add.

Growing your Definition of Done (DoD)

It’s super important that quality is always increasing, and that means that you will need to at least reflect on your Definition of Done on a regular cadence. In Scrum, this cadence is defined by your Sprint length, and you have a Kaizen moment at the Sprint Retrospective. That does not mean that you don’t reflect on your DOD all the time, you do. You reflect continuously on whether your increment currently meets your DoD, and what youd need to do to get it there. You should always be reflecting on whether your DoD fits your needs. If your Developers finds that something is missing from the DoD halfway through the Sprint, then they should go ahead and add it, making sure that they are not endangering the Sprint Goal.

You may discover that you have a performance problem with your product as David Corbin pointed out in my previous post. How do we make sure that we fix that issue? As I see it there are two pieces to this once you are in flight. You can Scrumble (stop Sprinting because of poor quality), and fix it, or you can integrate this new knowledge into your product cycle.

If it is a significant issue that results in you not having working software, then you need to stop and fix. In Scrum, this is called a Scrumble, as a reflection that the Developers stumbled because something is missing. You should stop adding new features and create a usable increment before you continue Sprinting and adding new features. Once you have repaired the issue, you can increase your Definition of Done to make sure that all future Increments meet the new requirements.

If it is less significant, you might want to keep working and add what you need to your Product Backlog. You can then deliver improvements over the next few Sprints that mitigate and then resolve the identified issue. Once you have resolved it, you can then pin the outcome by adding something to your DoD.

Always look for ways that you can increase your quality. What does your definition of done look like today?

Example Definitions of Done

Here are some examples of Done from various teams, real and fictitious.

Azure DevOps

FABRIKAM TEAM

CONTOSO TEAM

NORTHWIND TEAM

TAILSPIN TEAM

Views:
Subscribe
Product Development

Explains how a clear Definition of Done in Scrum ensures consistent quality, team alignment, and customer satisfaction across all projects, regardless …

Videos Videos
Read more about Why 'Definition of Done' is Crucial for Success in Scrum
Product Development

Explains how the Definition of Done evolves in Scrum, aligning team practices with organisational standards to ensure consistent quality, compliance, …

Blog Blog
Read more about Your Evolving Definition of Done
Scrum

Explains how to create, apply, and improve a Definition of Done (DoD) in Scrum to ensure software quality, transparency, and consistent delivery of …

Blog Blog
Read more about Getting started with a Definition of Done (DoD)
Engineering Excellence

Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product delivery.

Videos Videos
Read more about Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust—And How to Raise the Bar
Product Development

Explains the difference between subjective goals and the objective Definition of Done in Scrum, highlighting how clear, measurable criteria ensure …

Blog Blog
Read more about Definition of Done - Objective vs Subjective
Scrum

Lack of a clear, enforced Definition of Done leads to hidden risks, unreliable forecasts, and eroded trust in delivery, undermining predictability and …

Signals Signals
Read more about Executives want predictability
Scrum

Scrum Teams uphold, not lower, quality by strictly following and evolving the Definition of Done, ensuring predictable releases and reducing technical …

Signals Signals
Read more about Scrum Teams don’t set the bar for quality—they meet it
Scrum

Scrum Teams must consistently meet a clear, non-negotiable Definition of Done to ensure quality, manage risk, and prevent technical debt in every …

Signals Signals
Read more about Scrum Teams don’t set the bar for quality—they meet it
Engineering Excellence

Unlock a smarter Definition of Done—start small, evolve standards, and build team momentum without overwhelm. Discover how progress drives excellence.

Videos Videos
Read more about How to Evolve Your Definition of Done: Start Small, Grow Smarter, and Build Lasting Momentum
Scrum

Explains why a clear Definition of Done is vital in Agile and Scrum for quality delivery, transparency, and risk mitigation, with tips for team …

Videos Videos
Read more about Unlocking Success in Agile: Why Your Definition of Done is Essential for Quality Delivery
Engineering Excellence

Stop paying the hidden costs of weak delivery. Discover how a strong, shared definition of done builds trust, quality, and real agility in your team.

Videos Videos
Read more about Stop Paying the Hidden Costs of Weak Delivery: Why a Strong Definition of Done Transforms Your Team’s Results
Engineering Excellence

Struggling with inconsistent delivery? Discover why a shared definition of done is key to predictable, high-quality results your teams—and …

Videos Videos
Read more about Why a Shared Definition of Done Is the Secret to Consistent, Predictable Quality in Agile Teams
Scrum

The Definition of Done can evolve to improve quality but should not be weakened or vary per backlog item. Consistency ensures transparency and …

Blog Blog
Read more about Can the Definition of Done change per Sprint?
Product Development

Transform your definition of done into a strategic advantage—deliver real value, reduce risk, and drive business impact with every sprint.

Videos Videos
Read more about Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth
Product Development

Explores how Agile teams can clarify and align on the true meaning of "done" to ensure quality, reduce rework, and meet leadership expectations …

Videos Videos
Read more about Bridging the Gap: Understanding the True Meaning of "Done" in Agile Teams
Product Development

Unlock your team's true potential—discover why a powerful definition of done drives real business impact, customer value, and lasting competitive …

Videos Videos
Read more about Why Your Definition of Done Is the Secret Weapon Your Team Needs to Win
Product Development

Stop confusing acceptance criteria with definition of done—learn the crucial difference to boost quality, speed, and trust in your agile delivery.

Videos Videos
Read more about Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster
Engineering Excellence

Stop flying blind after release—learn why telemetry is vital to your Definition of Done and how real feedback drives better software, value, and team …

Videos Videos
Read more about Stop Flying Blind: Why Telemetry Belongs in Your Definition of Done
Product Development

Explores why diligence—consistent attention to quality and standards—is vital in Agile teams, how it’s often overlooked, and practical steps to foster …

Videos Videos
Read more about The Overlooked Virtue of Agility: Diligence
Product Development

Explains how to maintain clear, measurable quality standards with the Definition of Done, while avoiding confusion with acceptance criteria and …

Blog Blog
Read more about The Definition of Done: Ensuring Quality without Compromising Value
Method

Explains the Definition of Done, its purpose, key steps, and how to assess when work is complete in agile projects, including practical exercises and …

Workshops Workshops
Read more about Definition of Done
Engineering Excellence

Explores how technical excellence in Agile development reduces risk, prevents technical debt, and boosts product quality and delivery speed through …

Videos Videos
Read more about The Power of Technical Excellence in Agile Development
Engineering Excellence

Stop firefighting late-stage bugs—discover how shifting left saves time, money, and reputation by building quality in from the start. Learn the …

Videos Videos
Read more about Stop Firefighting Bugs: Why Shifting Left Saves Time, Money, and Your Reputation
Engineering Excellence

Frequent changes to the Definition of Done reduce team quality and predictability. Consistent, enforced standards are key to reliable delivery and …

Signals Signals
Read more about A changing Definition of Done undermines quality and predictability in teams
Product Development

Releases feel risky when teams lack a clear Definition of Done. Learn how a strong DoD ensures stress-free, reliable software delivery with built-in …

Signals Signals
Read more about If every release feels high-risk, you lack a true Definition of Done
Engineering Excellence

Team issues with quality or delivery often stem from weak systems, lacking clear standards, automation, and leadership support—not just team …

Signals Signals
Read more about If teams struggle with quality or delivery, the problem is often the system
Scrum

Transform your leadership with the Professional Scrum Master course. Master Scrum principles, enhance team collaboration, and drive organisational …

Course Course
Read more about Professional Scrum Master (PSM) Course with Certification

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Emerson Process Management Logo

Emerson Process Management

Xceptor - Process and Data Automation Logo

Xceptor - Process and Data Automation

Boeing Logo

Boeing

Teleplan Logo

Teleplan

Milliman Logo

Milliman

Flowmaster (a Mentor Graphics Company) Logo

Flowmaster (a Mentor Graphics Company)

Sage Logo

Sage

Lean SA Logo

Lean SA

DFDS Logo

DFDS

NIT A/S

Cognizant Microsoft Business Group (MBG) Logo

Cognizant Microsoft Business Group (MBG)

Microsoft Logo

Microsoft

Slaughter and May Logo

Slaughter and May

CR2

Higher Education Statistics Agency Logo

Higher Education Statistics Agency

Alignment Healthcare Logo

Alignment Healthcare

Lockheed Martin Logo

Lockheed Martin

Ericson Logo

Ericson

Department of Work and Pensions (UK) Logo

Department of Work and Pensions (UK)

Nottingham County Council Logo

Nottingham County Council

Ghana Police Service Logo

Ghana Police Service

New Hampshire Supreme Court Logo

New Hampshire Supreme Court

Royal Air Force Logo

Royal Air Force

Washington Department of Transport Logo

Washington Department of Transport

Genus Breeding Ltd Logo

Genus Breeding Ltd

Illumina Logo

Illumina

Lockheed Martin Logo

Lockheed Martin

Kongsberg Maritime Logo

Kongsberg Maritime

Qualco Logo

Qualco

Schlumberger Logo

Schlumberger