Definition of Done

Dear agile team, Don't let anything that's not DONE into your production.

In this practical and dirty world of software development, many roles work together on a user story and do their tasks to complete the user story. For a role, when s/he finishes his tasks, s/he might think that s/he is done. But we need some tool which will help the team and the product owner to get the confidence that a user story is really "Done" Done. With different members doing work that is "finished" at different times, how can the team and the Product Owner, know when a story has truly been completed?

Definition of Done (we will call it DOD henceforth) gives a confidence to the team and product owner that the story is done and can be released to production any time. Definition of Done is a list of things that must be finished before the work/story is accepted by the Product Owner. Merely testing the acceptance criteria can not ensure that the story is done. Acceptance Criteria is just a part of DOD. DOD also has lot of other things like -

• code is checked-in to all branches.
• all the defects found during testing of the story are either closed or deferred.
• code review comments are closed.
• training documents are updated.
• and so on...

Before accepting a story, Product Owner (and/or team) must validate that story against the DOD and then mark it as Accepted. There could be some scenarios, where some items from DOD are not valid and there those could be marked as "NA" (Not Applicable).

As Mike Cohn says, you can think of the Definition of Done as an extra set of acceptance criteria that are rubber stamped onto each and every user story.

How to build a DOD

Creating a DOD is a one time activity. But periodically (may be once in 6 months), you should re-visit the DOD and update it as needed.

Before your team moves into agile, (Or to update your existing DOD) do below exercise:

1. Educate your stakeholders about DOD. You can send them this blog link.
2. Send meeting invite to all the stakeholders of your team + the team with the notice saying "We will need to define our DOD, so come prepared with your checklist, which you would generally see before accepting any user story".
3. In the meeting, ask every one to write their items on a sticky note. Past all the sticky notes on a big wall.
4. Now, ask everyone to visit the wall, remove duplicates.
5. Now, pick a volunteer and ask him to read out loud each item from the wall.
6. Ask the team if they want this item in DOD. If not, why? If yes, why?
7. There will be certainly some disagreements, which must be resolved through discussions.
8. Then put all the agreed items in an xls, and store it on central location or post in on some big wall near to your team area.
9. This will be your DOD and your team should follow it for every story. If the story satisfies these criterion, then only mark the story as Done and move it to production.

How to use the DOD

1. Pick the story which you want to accept.
2. Open the DOD on another screen.
3. Start ticking the items from DOD which are satisfied by the story.
4. Mark the items with X, which do not get fulfilled for this story.
5. Discuss and negotiate with the team and then accept/reject the story with reasons.
6. The good way is say No if at least one of the criteria in the DOD is not fulfilled.
7. Mention the discussions in story, for future reference.

Benefits

1. You can proactively catch some of the risks. E.g. your DOD may have an item saying "All the defects found while testing this story should be either closed or deferred.". And you find out that out of 5 defects, 4 are closed but 1 is still open and missed by the development team. This will trigger the discussions and you avoid the risk of this defect getting leaked into 
2. DOD gives team a confidence that they are making a quality delivery.
3. DOD creates common understanding between team members and PO about what means "Done". We do not want to deliver the stories which are "kind of done" or "almost done". We do not want to eat half-baked cake and suffer from loose-motions for next 10 days!

Pitfalls

1. Some product owners try to make DOD as a law enforcement document and start rejecting every other story during acceptance phase. This is the most common pitfall. While its true that DOD is checked for each story before acceptance, it is also true that every list item in DOD might not be valid for each user story. For e.g. your DOD might have an item saying "Is the code checked in?", and you answer "No" and reject the story. But, some stories, in real world, do not need code check-in. Those might need just system parameter changes. So this time, you would want to accept for this story.
2. DOD once prepared, must be re-visited after some period. If you do not revise it, then it will become stale and might not be useful. A team’s DOD won’t remain the same throughout the lifetime of the project and neither should it. As a team becomes more effective and productive, as they learn to work better together, they will naturally enhance and refine their DOD to produce more valuable and better quality features. They will recognize patterns in the processes that are required to produce high quality features and start adding these to the DOD.

As a good practice

• As a Product Owner, you can print the DOD and stick it on your desk, so that while accepting a story, you can quickly validate it. For some technical items in DOD, you can setup meeting with one of your team member to validate those items.
• Like DOD is validated against each story, the same way, DOD can also be created for a release and validated for the release items to help "Go / No Go" decision for a release.

Example

Click here to have a look at an example DOD.