Skip to main content

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine.
What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a shared understanding of what it means to be finished, so everybody in the project means the same thing when they say "it's done". More subtly, the definition of Done is an expression of the team's quality standards. A more rigorous definition of Done will be associated with higher quality software. Generally the team will become more productive ("have a higher velocity") as their definition of Done becomes more stringent, because they will spend less time fixing old problems. Rework all but disappears.

So the Definition of Done should evolve as the project advances. Here is the first Definition of Done my team used when we started to develop the HappinessApp:
  1. Unit tests written and green
  2. Source code committed on server
  3. Jenkins built version and all tests green
  4. Code review completed (or pair-programmed)
  5. How-to-Demo verified before presentation to Product Owner
  6. Ok from Product Owner
For each Product Backlog Item ("story"), my team and I agreed on a workflow to show that the story has been implemented correctly. We call this "how-to-demo." More subtly, the combination of story title and how-to-demo limits the scope of the story and prevents scope creep during the sprint!

This definition served us well until we started releasing our beta test results to customers, starting with me. I was are first customer. So we enhanced the definition of done as follows:
  1. Potentially releasable build available for download 
  2. Summary of changes updated to include newly implemented features
  3. Inactive/unimplemented features hidden or greyed out (not executable)
  4. Unit tests written and green
  5. Source code committed on server
  6. Jenkins built version and all tests green
  7. Code review completed (or pair-programmed)
  8. How to Demo verified before presentation to Product Owner
  9. Ok from Product Owner
Very quickly, we discovered that an upgrade on an actual iPhone would overwrite existing user data. This was a bad thing (especially for a diary application!), so we added another point:
  1. Upgrade verified while keeping all user data intact.
  2. Potentially releasable build available for download 
  3. Summary of changes updated to include newly implemented features
  4. Inactive/unimplemented features hidden or greyed out (not executable)
  5. Unit tests written and green
  6. Source code committed on server
  7. Jenkins built version and all tests green
  8. Code review completed (or pair-programmed)
  9. How to Demo verified before presentation to Product Owner
  10. Ok from Product Owner

This version held up pretty well through the next 8 sprints or so until we finished developing the beta version. We did experiment with two other points which were inspired by Release It, the guide to designing and deploying production-ready software:
  1. Design review -> list of how-could-this-feature-break failure cases (at least 3 unhappy paths)
  2. Identified failure cases covered in design decision or unit test
Our developers had difficulties living this one, so we have put them on hold (until something important breaks, then I, as Product Owner, will have the basis for a discussion with the team ;-)

In retrospect, the Definition of Done and the engineering practices they imply have served us well. The product has been remarkably free of technical issues, so the team has achieved the proverbial "technical success." Next step for us is to get it out there and help in become a genuine success.

The Definition of Done is important to Scrum, but there are many facets to done-ness, of which the Definition of Done only covers a few. "What do you mean it's done? Only two little features have been implemented! Before we can call it done, all 150 features must be implemented!" I look forward to revisiting this topic in a future article, tentatively titled "The Three Faces of Done." In the mean time, my CSM Students (for whom this article was written) can explain it do you!

[Update 29-May-14: Well, I finally wrote The Three Faces of Done. Check it out!]


I think that's still a rather programmer-centric definition of done! Unless the product owner has given the go-ahead and the function has already left the nest, then the function is not done. It should not be "done" to one person and "not done" to another in any circumstance, including between product owner and programmer. If it is, they need to isolate and map out their difference of opinion, and use language that they can both agree on.

Popular posts from this blog

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…