Getting started with a Definition of Done (DoD)


In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).

Updated to reflect the 2020 Scrum Guide!


Your Developers are ultimately responsible for creating done increments of working software. Done Increments. Done.

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. Not just for each PBI.

“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.

What is a Definition of Done (DoD)

You need to start somewhere, and most often we don’t have a greenfield product. Either we are handed an existing product, or we are the team that built it and are switching to Scrum. Wherever your product originated, the code, and thus the product, will not currently be working software. How can it be when you don’t have a definition of what working means? So what do you do?

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 short, measurable checklist – try and have things on your DoD that can be measured, that you can test the outcome, preferably in an automated fashion.
  • Mirrors shippable – While you might not have shipped your product, although we recommended it, you should have that choice. Your Product Owner should be able to say, at the Sprint Review: “That’s Awesome… lets ship it.”.
  • No further work – There should be no further work required from the Developers to ship your product to production. Any additional work means that you were not Done, and it takes away from the Product Owner capacity for the next iteration. Ideally, you have a fully automated process for delivering software, and never use staggered iterations for delivery.

Your short, measurable checklist that mirrors usable and results in no further work required to ship your product needs to be defined. I find the best 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 Defenition 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.

My first Definition of Done (DoD)

Your Definition of Done does not just magically appear, and your software does not magically comply. 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 workshop with the entire Scrum Team, and likely some other domain experts. 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.

Some examples of things to put on your definition of done:

  • Increment Passes SonarCube checks with no Critical errors – You will be increasing over time, so maybe you need to say “Code Passes SonarCube checks with no more than 50 Critical errors” then work on it over time.
  • Increment’s Code Coverage stays the same or gets higher – Looking at a specific measure, like 90%, of code coverage is a read hearing and tells you nothing of code quality. However, it might be advantageous to monitor and measure for adverse change in code coverage, and we always advocate for TDD practices.
  • Increment meets agreed engineering standards – You should decide rules for naming of methods, tests, variables and everything in-between. Start small and add over time. Link to your agreed standards on a Wiki and continuously improve and expand your rules. Automate if possible.
  • Acceptance Criteria for Increment pass – Making sure you at least meet the prescribed criteria is a laudable goal and automating them with ATDD practices is even better.
  • Acceptance Tests for Increment are Automated – Make sure that you automate all of your tests. If you think something will break, then you should have a test for it.
  • Security Checks Pass on Increment – Use an automated tool as part of your build and check for known security vulnerabilities. You will not find all of your security issues, but at least don’t do things we know to be reflective of poor Security.
  • Increment meets agreed UX standards – Again, have a Wiki page and make sure that you check it twice. If you are not using an automated DoD entry, then you need to agree as a Team that you have met the criteria.
  • Increment meets agreed Architectural Guidelines – Wiki’s are fantastic for this, but automate what you can.

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, but you can and should add to that quality bar.

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.

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 you 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?

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Professional Scrum Product Owner online 5th June 2023
5-8 Jun, 2023
09:30-13:30 BST
4 half-days
Live Virtual PAL Evidence-Based Management Online on 19th June 2023
19-20 Jun, 2023
09:00-13:00 BST
2 half-days
APS 19th June 2023
19-22 Jun, 2023
09:00-13:00 EDT
4 half-days
Live Virtual Professional Scrum Master Online on 26th June 2023
26-29 Jun, 2023
09:00-13:00 EDT
4 half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood Why do you encourage people to follow a certification path in their career journey? I would encourage you to follow a scrum certification path for the same reason that people go to university. The same reason that people do any course or certification. It gets you a foot in …
Martin Hinshelwood What will you learn on the PSM II course? There are two main things that most scrum masters will learn on the PSM II or Advanced Professional Scrum Master course. That they haven’t been working effectively as a scrum master to date. That they are there to empower and …
Martin Hinshelwood
In Scrum Events across the world, I hear repeated the phrase “that’s how agile works” when describing behaviours that are both unprofessional and the very opposite of an agile mindset. These behaviours will inhibit agility and are a result of a lack of understanding of the underlying principles. We need …
Martin Hinshelwood What is the most common Aha moment people have in a scrum course? It depends on the scrum course they are attending. The content presented in the Applying Professional Scrum (APS) course leads to very different epiphanies when compared to the content presented on an Advanced Professional Scrum Master …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.