Get certified - Transform your world of work today


Why Use a Definition of Done in an Agile Project?

The Real Value of a Definition of Done

24 January 2014

Christian Vos
Rood Mitek

If you want to learn to play the piano, it's going to be a tough endeavor if it takes 30 minutes before your piano produces a sound after you press a key.

When you demonstrate your software just before the deadline, you know for sure that the project won't finish early. If you demonstrate it every week and implementation is done based on the product owner's priorities, there is a big chance the product owner will approve the application even before all requested features are implemented.

Feedback will help you improve, learn, and reach your goal more effectively.

It's important that you get such feedback early and often, and iterative development can facilitate this. What you actually get feedback on is defined in the Definition of Done. The Definition of Done defines all steps necessary to deliver a finished increment with the best quality possible at the end of a sprint. The more you do in your sprint, you more you get feedback on, and the more you can improve and learn.

This introduces the first reason for using a Definition of Done:

Definition of feedback and improvement

When the Definition of Done is complete, it will define all steps to deliver a finished increment, and therefore it creates feedback regarding the product and also regarding the process within the sprint.

With steps such as the sprint demo, performance testing, acceptance testing, etc., you generate feedback on the product. When the product owner is trying out the application during the demo, he will give his feedback. The acceptance tests generate continuous feedback on the acceptance criteria, especially when all criteria are implemented with SpecFlow or any other framework of specification by example.

With steps such as peer review and deployment, you get more feedback on the process: Are the deployment processes correct? Are we coding like we want to? And so on.

The more steps defined in the Definition of Done, the more feedback you will get.

The second reason for using the Definition of Done is that it improves release planning

Typically when finishing a sprint, different items are still left undone. Some bugs are still in the code, integration testing is not yet done, performance testing in a production-like environment is not done, the manual is not up to date, etc. All this work has to be done at some time. The problem with this undone work is that it piles up every sprint; every feature that is added will let this undone work grow.

What happens in an Agile project release planning session is that, based on the number of user stories, points and velocity for a release are planned. For example, when the team has a velocity of 6 and 23 user story points need to be implemented, the release date can take place after 4 sprints.


The problem is that after 4 sprints, this undone work is still there. Many teams solve this by introducing so-called "hardening sprints" or "release sprints." These sprints are used to, for example, create the deployment packages, solve some last bugs, do some final testing, and so on -- everything to make the software ready for production.

Undone work and release sprints

The problem with these release sprints is that they are a bad Agile practice. You are trying to timebox work that is unknown (last-minute tests can reveal all kinds of bugs), unplanned, not estimated -- but still it is really necessary, and it all has to be done in a fixed amount of time and before the release date.

In addition, your release date doesn't match with your release planning. Instead of planning the release based on sprints defined in the release planning, it is now based on "planned" sprints plus one or more extra release sprints.

When the team defines a complete Definition of Done and applies it, all the undone work is done within the sprints and no release sprints are necessary.

Applying a complete or ideal Definition of Done also gives sense to burn-down charts

A burn-down chart shows the amount of work still to be done in the progress of time represented by the green line.

Release Burndown Chart

This burn-down chart is well visible in most teams but will give a false indication of when the software is production-ready. When the Definition of Done is not applied well, undone work will pile up in every sprint, represented by the orange line, and this line is usually not visible in regular burn-down charts.

Release Burndown Chart

The line showing the ideal burn-down line plus the undone work line represent the real burn-down chart, but this is usually not shown, and the product owner is caught by surprise to realize, after four sprints, that there is still work to be done even though the burn-down chart showed differently.

When no release sprints are used, the delta of the black line and the green line shows the risk that is delayed. If the team doesn't pick up this work during a sprint, it will reveal itself in production. For example, when no performance testing is done during the sprints, there is a chance that later an issue regarding performance can occur in production.

Almost done is not done at all

A typical conversation that most developers will recognize goes like this:
Product owner (PO): Is the software done?
Developer (Dev): Yes, almost.
PO: Can we go to production?
Dev: No, not yet.
PO: Why not?
Dev: Well, some bugs have to be solved, some integration tests still have to be run, release packages have to updated, etc.
PO: When can we go to production ?
Dev: I don't know. . . .

To avoid these kinds of discussions, there should be a common understanding of what is meant by "done" software. A Definition of Done will create more transparency about what the team is doing in every sprint, and what is delivered. When, for example, the Definition of Done doesn't say anything about performance testing in a production-like environment because the organization is not fit to accomplish this in every sprint, then the product owner is aware of this.

The Definition of Done minimizes the delay of risk

When the Definition of Done is complete, with all the steps necessary to deliver an increment with the best quality, you are minimizing the delay of risk. All steps in the Definition of Done are subjected to feedback and therefore risky items are inspected, adapted, and improved as much as possible in an early stage, and as many times as there are sprints. In other words, risks are covered several times in early stages of the project.

The smaller the Definition of Done, the more undone work is likely to pile up after every sprint. This undone work is not subjected to feedback but will reveal itself somewhere, sometime, in production.

A complete Definition of Done will minimize this undone work and therefore minimize the delay of risk.

The Definition of Done represents the agility, quality, and maturity of the team

A team is able to complete a (new) feature in one sprint and release it immediately to production with all steps defined in the Definition of Done necessary to guarantee the best quality.

The agility of the team shows in the fact that it can release a feature to production in every sprint. The quality of the team is represented by the number of steps in the Definition of Done that are applied when releasing this feature to production.

How to put the Definition of Done into practice

Start off by defining two versions of the Definition of Done: one ideal, and one current. The possible reasons to need two versions are competence and maturity.

Competence is a real reason, because not every team is capable of doing everything in one sprint in order to deliver a production-ready product. This is especially true at the beginning of a project. To deliver a finished increment in one sprint, you need to automate many steps in the Definition of Done. For example, automate build processes, automate tests, automate deployment, maybe automate some documentation, etc. This can be complex and time-consuming to set up.

Maturity is another reason why the Definition of Done is perhaps not yet ideal. Some teams are just not ready enough to want to do all the steps in one sprint. They feel it's better to do the regression tests only at the end of all the sprints, or to update the manual just before going to production, because they feel it isn't necessary or takes too much time to do this in every sprint. Those teams don't have an Agile mind-set yet.

The ideal Definition of Done defines all steps necessary to deliver a finished increment from development till deployment in production. No further work is needed.

The current Definition of Done defines the steps the team is currently capable of doing in one sprint.

It's best is to make both visible on the wall so that what the team is delivering in the sprint is transparent to the product owner, and to create a common understanding of what is done. What's important to understand is that the product owner is also responsible if the team is not using an ideal Definition of Done. He can decide that performance testing is not needed every sprint because it has never been a issue on the much faster production servers, and because the team hasn't yet automated performance testing, so it takes too much time to do it every sprint. With this decision, the product owner consciously delays the (potential) risk of having a performance issue in production.

If the product owner wants to have more steps in the current Definition of Done -- for example, automated acceptance tests -- he should make it a priority that a framework is created that facilitates the automation of these tests. This can be done by giving the work item containing this framework a higher priority in the product backlog.

So, putting two versions on the wall will create transparency for the product owner. It represents the current capability of the team and shows what could be improved. The team can try to regularly expand the current Definition of Done with steps from the ideal Definition of Done. Expanding the Definition of Done will actually mean growing in quality and maturity.


A good Definition of Done will help with:
  • Getting feedback and improving your product and process
  • Better release planning
  • Giving burn-down charts sense
  • Minimizing the delay of risk
  • Improving team quality and agility
  • Creating transparency for stakeholders

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.3 (10 ratings)


Iulian Moldovan, CSM, 1/24/2014 1:13:59 AM
Good article and explanations, congrats!
The DoD depicted above seems more likely a DoD per increment (sprint), which may consist in multiple, maybe different type of user stories. How do you cope with this situation in the DoD? You adapt DoD in such a way that handles all story types?

Supposing in Sprint 10 you have a story to develop a new feature X and to write the user manual for another feature Y developed in one of the previous sprints, how do you handle checking of DoD? Overall per sprint result, or using different DoD for the development story and another one for the user manual writing story?

Christian Vos, CSM, 1/24/2014 5:47:32 AM
Hello Lulian,

Thanks for your response.
The DoD in this article reflects indeed actions done regarding sprints.
It is difficult to compile a DoD that handles all possible kind of user stories.
Important is to recognize that the DoD is not a contract but a (strong) guideline of applicable steps that
define done and in such they can be retrospected
When you are creating userstories that for example can't be performance tested then this step in the DoD simply doesn't apply.
You can also define your userstories in such a manner that updating documentation, like a manual, interface documentation etc, is part of that userstory.
Adding a feature to the application is not done when that documentation is not done.
In this way, updating documentation is part of the DoD too.

Arijit Sarbagna, CSP,CSM, 1/24/2014 10:23:31 PM
@Christian: Loved your article, very well explained & you shared the practical problems faced by many Agile projects. Good one!
Wouter Tengeler, CSM,CSPO, 1/27/2014 2:51:08 AM
@Christian: Great article. I like the idea of having a current DoD and a target one. I did not teach it like that, but i will from now on.

But if you are working with a current DoD which is not yet perfect (if it will ever be). Than i would recomment adding stories that will complement the difference between the current DoD and the target DoD to make the (technical) debts visible. I would opt to add a story to write a user manual just to be transparant about the task so everyone knows that it is something that still needs to be done. When the team matures you will add the writing of the manuals to the DoD.

David Lowe, CSP,CSM, 1/28/2014 1:57:08 PM
Although I'm sure many will tell you that having 2 DoDs is a bad idea because the ideal will just get forgotten, I think it's a clever idea: at least it accepts what the team knows it SHOULD be doing. Of course, how you move towards that ideal is another matter!
Colin Sweetman, CSM, 2/4/2014 10:49:19 AM
Very good article, Christian. Well written, supported by useful digrams and covering an important topic. Any Scrum practioner with any significant experience will have come across the hidden monster of accruing technical debt. In effect your two versions of DoD form a rolling piece of gap analysis that can be a valuable tool to inspect and adapt.
Colin Sweetman, CSM, 2/5/2014 4:06:22 AM
Very good article, Christian. Well written, supported by useful digrams and covering an important topic. Any Scrum practioner with any significant experience will have come across the hidden monster of accruing technical debt. In effect your two versions of DoD form a rolling piece of gap analysis that can be a valuable tool to inspect and adapt.
Ravishankar N, CSM, 2/7/2014 2:23:05 AM
Good artice Christian. Spot on when you emphasized the need for a common understading of the DoD between Dev and the PO.

I liked the idea of two DoDs. However as the team learns and the process matures, the team should move towards the Ideal DoD and drop the 'Current' DoD.
Gurpreet Singh, CSP,CSM,CSPO, 5/11/2014 5:55:47 PM
Very nice article! Bravo! The 2 definitions of DOD is tricky; yet it gives a true and complete picture to PO and the team!

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up