Definition of Done
Is it done, is it done done, or is it done done done?
If you’re in the business of application development, you’ve asked that question before. So what is the definition of done? When asking the question, it’s important to note who you are and your level in the organization. Delivery teams, program teams, and portfolio teams define done differently. What we know for sure, is that we need a clear definition of done at each level of the organization.
Definition of Done
The definition of done (DoD) is when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system. We must meet the definition of done to ensure quality. It lowers rework, by preventing user stories that don’t meet the definition from being promoted to higher level environments. It will prevent features that don’t meet the definition from being delivered to the customer or user.
User Stories
The most common use of DoD is on the delivery team level. Done on this level means the Product Owner reviewed and accepted the user story. Once accepted, the “done” user story will contribute to the team velocity. You must meet all of the defined criteria or the user story isn’t done.
User Story DoD Examples:
- Unit tests passed
- Code reviewed
- Acceptance criteria met
- Functional tests passed
- Non-Functional requirements met
- Product Owner accepts the User Story
Features
Done on this level may mean it qualifies to add to a release. Not all user stories need to be completed. Rather, it means the feature may be sufficient to satisfy the need. Once accepted, the done feature will contribute to the release velocity. Again, you must meet all of the defined criteria or the feature isn’t done.
Feature DoD Examples:
- Acceptance criteria met
- Integrated into a clean build
- Promoted to higher level environment
- Automated regression tests pass
- Feature level functional tests passed
- Non-Functional requirements met
- Meets compliance requirements
- Functionality documented in necessary user user documentation
Epics
Done on this level may refer to a organizational strategic priority, portfolio plan item, or some other collection of features that satisfied a market need. Not all user stories or features need to be completed. Rather, the epic may be sufficient to satisfy the need. Once accepted, the done epic will contribute to throughput calculations to see if the supply is in balance with demand.
Epic DoD Examples:
- Non-Functional requirements met
- End-to-end integration completed
- Regression tests pass
- Promoted to production environment
- Meets defined market expectations
Summary
Just as the definition of ready is super important, so is the definition of done. Never start work on something until you have agreed on the definition. Be consistent. Be clear. Have a shared understanding.
Comments (17)
Amit J Bhattacharyya
Thanks Derek for this neat and crisp compilation on DoD.
I just have seen from experience that a number of times the user story DoD and the features DoD really overlaps or coincides in real life.
I totally appreciate the segregation here and would agree that the last 2 points of features DoD is quite exclusive. But I have seen that in the scrum lifecycle of a user story or stories if “Automated regression tests pass” was -ve then QA teams would not approve it and raise issues against it and then it is not able to proceed to the Product Owner and other stakeholders for the Done assessment itself.
The other one I have seen, being a part of necessities for user story DoD is “Integrated into a clean build”. As without that, the development team will not be able to pass the hurdle to prove that delivered story is really releasable which then in turns hurts it’s efforts to earn the credibility of done.
Would love to know your thoughts and yes definitely :) I will be sharing this good post on twitter.
Zeeshan Siddiqui
Should ‘No open Critical/High Severity defects’ be included in DoD?
Absolutely, I agree it should. I don’t specifically call it out, but I believe that should be part of the fundamental acceptance criteria. Quality should be a core consideration.
Faaz Ahmad Khan
When we add the point ‘Functional tests passed’ or ‘Feature level functional tests passed’ in DoD then doesn’t it implicitly enforce that there are ‘No open Critical/High Severity defects’?
David Murphy
It does, but sometimes it’s worth being explicit.
Gayathri Nimmakayala
How elaborate do you think the DoD should be ? There is a chance it can end up looking like a to-do list . Where do we draw the line ?
David Murphy
For me, DoD should be a max of 10 items and probably more like 7. More than that then people won’t bother or will lose the will to live.
Derek Emrie
Let’s face it, endless meetings, meetings that are not kept to a very predictable time span will drain anyone’s “will to live”; it is important to keep things realistic and reconvene if necessary for further details to be discussed. One must be able to breath!
Bang Pham
Every meetings must be time-bound. DoD is for reference, the last determination is able to end the task, not the endless meetings!
Peter Joyless
4h Review, 3h Retro, 15m Dailys, 8h Planning, max. 10 % Refinements in a month are 1:45h per day at max
Paramjit Aujla
Dear Derek,
First of all, thanks for the nicely crafted article.
I would to share my practice experience about regression and UAT being conducted for all features going out for release. This makes sure nothing breaks in production especially in retail facing applications.
Regards
Paramjit
Sach
Do we need to define what the DoD or DoR in each user story separately? I’m currently under the impression that neither DoR or DoD needs to be written as a statement rather it’s an agreement within the team. In some organizations that I worked previously mandates that you write the DoD and DoR as a statement within the user story. Thank you in-advance.
Nev Harvey
Why do you have separate Definitions of Done for User Stories, Features and Epics?
Sam T
Some things are not efficient to do on a story level. Some examples:
* Security Testing (often done by an external party) : you will not ask a security tester to validate each story. You will probably have an agreement with them for a feature.
* Writing user manuals, training, instruct a helpdesk is also something you don’t want to do on a story level but want to put in the effort when the feature is nearing completion (or even Epic e.g. when training a large number of people).
* E2E load/stress/performance testing is often also something you don’t want to be doing for every little user story as you will annoy other teams when you keep on monopolizing the test environments.
Moving these to the Feature DoD help you to keep the stories flowing but still makes sure these are not forgotten.
Chaitra kotagal
Hi Derek,
This is quite helpful, thanks to begin with.
My current team is quite new and its a start up. We are trying to build in the culture of Scrum, agile which obviously requires a lot of iterations considering we are trying to adapt and not force. With the definition of done, in my previous orgs we mostly had product owner approval as the last step but here the team wants “release to prod” incorporated in DoD.
Again, we don’t have a releasable candidate every sprint.
I know the answer to this but would like to listen to the experts at this.
Thanks
Chaitra
Andy Zwerin
@Chaitra, one possible reason not to include “release to prod” in your DoD is that User Acceptance Testing (UAT) may be required before something is released to prod and the UAT is quite often not going to be completed during the same Sprint as the user story/feature.
Rajan Rao
This might be useful to you if you are following Scrum: https://www.linkedin.com/feed/update/urn:li:activity:7087867547915538432/