Skip to main content

The Three Faces of Done

How can you expect me to test it if it's not done?!
I hear this question a lot from people just starting out with Scrum. What does it mean for something to be "Done" in Scrum?

Build the Right Thing, Build it Right, Build Enough

Under Scrum, the objective is to produce a potentially shippable product every sprint. Scrum is an incremental framework, which means you achieve your overall goal incrementally. Each sprint, even each backlog item, produces an additional slice of the product. This slice is integrated with all previous slices into a whole. That potentially shippable whole is called the "Increment."

Everything that goes into the Increment has to be "Done" and the increment as whole has to be "Done." If it's not done, you can't ship it. So what does it mean for something to be done? That's what the Definition of Done is for.

The Definition of Done is an agreement between all the members of the Scrum Team: what does it mean in your context for something to be done? So regardless of who you ask on whether something is done, you should always get the same answer.

To come up with a Definition of Done, I have found it useful to look at Doneness in the context of three questions:
  1. Have we built the right thing? (External Quality)
  2. Have we built it right? (Internal Quality)
  3. Have we built enough value to justify releasing? (Fitness for Use) 

External Quality -- Building the right thing. 

We could call this "Customer's Intent."

Imagine you are buying a car. You ask the car dealer for a red car with 2 doors, leather seats, automatic transmission, air conditioning, heated seats, and probably some other essential features. Your dealer can't deliver that car right away, so you come to an agreement to order that car, and 30 days later, that car is sitting in dealer's lot, waiting for you to pick it up. Did you get the car you ordered?

You check the car against the order: color, transmission, number of doors, presence of air conditioning and heated seats. If it matches the order, you say, "yes, this is the car I ordered." The car conforms to what you ordered, so you say thank you and take the car home.

Customer Intent, or building the right thing, is usually reflected in some kind of acceptance test. When this test passes, the customer is happy. For a car, we know in advance what a car is and what features it can have, so defining the car by a list of acceptance tests (aka - order form) is easy to do, and most customers can order a car at that level alone.

In Scrum, customer intent is identified during the conversations between the Development Team and the Product Owner or other domain experts. (This is often called Estimation, Backlog Refinement, or Release Planning.) The Product Backlog item is enriched with the "confirmation" - a description to confirm that the solution or implementation satisfies the objectives set for it. Scrum does not define how to do this. In a software development context, some widely used practices include: 
  • a simple workflow, "How To Demo," to show that the feature is working correctly.
  • a set of conditions and expected results ("Given <a known state> when <some action occurs> then <expect some result>"), or even 
  • a collection of examples that pass or fail. For example, to convert integers to Roman Numerals, you might have a table that starts like this:
    0 -> #badInputError
    1 -> i
    2 -> ii
    3 -> iii
    4-> iv
The latter two are examples of Specification by Example and can lead to your specifications becoming automated test suites.

Internal Quality / Building it right

We could call this "Developer's Intent."

But how do you know that the car is legal to operate in your jurisdiction? How do you know that the air conditioning will produce enough cold air so that you can drive comfortably in the heat of summer (without being so cold as to cause respiratory illness!) ? How do you even know it was built according to the designs of the engineers who designed it? How do you know that your new car satisfies the larger requirements to be road legal in your jurisdiction? How do you know that the car will outlive the warrantee?

So many questions! Can you verify this as a customer or even as a (non-technical) Product Owner? 

In general you are dependent on the manufacturer to do their job right. In Scrum, it's harder, because you are building a product for the first time. While the Development Team is responsible for achieving "Done" for each feature they build, the whole Scrum Team is responsible for the quality of the product.

How does the Development Team ensure internal quality? At this level, the Definition of Done looks like a checklist. Here is a typical Definition of Done for a moderately mature Scrum team that develops Software for an iPhone/iPad environment:
  1. Unit tests written
  2. Code checked in
  3. Code review completed
  4. Improvements from review implemented
  5. All new unit tests green
  6. All existing unit tests stay green 
  7. Build available for download in TestFlight
  8. Acceptance tests verified by Development Team
  9. Done confirmed by Product Owner
All these points ensure building it right. The last two points create a link between internal and external quality so you build the right thing. The Development Team verifies to the best of their ability that the "Customer Intent" has been satisfied. The Product Owner has final say over whether a feature is done or not.

This example includes automated testing. Why? If something was Done in the last sprint, shouldn't it stay Done in this sprint? If not, how can you call it done? 

Personally, I have had the best results applying the Definition of Done to each backlog item, not to the increment as a whole.

Unfinished work

When deciding whether a backlog item is done or not, the Product Owner should ask the Team, "Can we release it?" If the team says, "Nope, we can't release it" (or any of its more subtle variations), then the work is not Done, and the appropriate response is "Why not?" The answer is un-Done work. It goes into the product backlog -- because it has to be finished before you can release -- and should be a subject of the next retrospective: How can we have less un-Done work at the end of the next sprint?

Completion / Fitness for Use

Under what conditions do you actually ship the increment? This is a judgement call. The Definition of Done is not a Definition of Complete or Definition of Releasable for the product as a whole. Assuming there is no un-Done work, the Product Owner may decide to release at any time. The product should be releasable by the end of each Sprint, and possibly more often than that. Very mature teams in very dynamic environments often strive to achieve continuous deployment.

Under Scrum, you achieve releasability incrementally by implementing one feature at a time. Eventually you will have implemented enough features that the Product Owner decides that implementing more features will not add more value to the product and/or the cost of releasing is justified by the value to be earned by the release. In this case, the Product Owner asks for a release. If the Increment is truly done, the Team will respond, "Sure, no problem!"

Create a Sample Definition of Done - (Non-Software)

What if you are not doing software? How does this apply? Just ask your team:
  1. How do we ensure we have built the right thing? (External Quality)
  2. How do we ensure we built it right? (Internal Quality)
So let's say you are a consultancy and you produce studies. How would you answer these questions? What quality standards does a study have to fulfil in your organization? The answer might look something like this:
  • Does it conform to the appropriate CI/CD?
  • Does it contain customer CI/CD?
  • Has it been spell checked?
  • Has it been proof-read?
  • Has it been fact-checked?
  • Does it have enough pictures and graphs?
  • Have we confirmed that the content represents value to the customer?
  • Does the content address a key goal of the study?
If each backlog item corresponds to a (sub)chapter of the study, then it is pretty straightforward to apply these tests for each new chapter as you write them!

How done is Done?

When is something really done? Ultimately, something is only done when everyone has lost interest in it.

So almost by definition, your Definition of Done will only be partially done in the greater scheme of things. Does Done include User Acceptance Testing? Does it include Customer Acceptance Testing? Does it include validation from the marketplace that the feature is necessary and desirable? Is it feasible to check these things on a feature by feature basis?

In general, you should strive to make you Definition of Done more extensive as your project moves forward. As Done becomes "done-er" your quality is rising, and with it, your productivity.

If there is no alternative to handing your product off to a downstream process, then understanding what it means to be ready for that process can be very helpful. When I developed an iPad app, I had to be sure that Apple would accept it according to their terms and conditions. So my team looked at the contract, and we figured out Apple's Definition of Ready, and made sure that our product conformed. As a consequence, we are able to get our apps on to the app store without too much hassle.

If you have a downstream process, one question to raise is how can you integrate those stakeholders better, so that you are more in synch on what Done means and what is really done. If you have stakeholders or customers who also have to accept the product, how can you get them more involved in your process so that Customer Acceptance Testing happens during the project, not at the end, and any testing at the end becomes more a rubber stamp formality than source of risk and surprises?

If you are building for the market, you don't really know if you have built the right thing until you have gotten that confirmation from the market. How would you integrate market validation into your process?

Summary: The Three Faces of Done in Scrum

Scrum says simply, we have to agree what "Done" means. The definition of Done should help you answer the first two of these three questions effectively:
  1. Have we built the right thing? 
  2. Have we built it right?
  3. Have we built enough value to justify releasing?
The third question is a judgement call, and getting that right is the Product Owner's responsibility!

There is a bonus question, especially when developing software: How do we ensure that what gets Done in this Sprint, stays Done in future Sprints?

If your team can answer all these questions well, you are on your way to high and predictable team performance, delivery dates and product quality!

Credits: This perspective on Done and the terminology used was inspired the Lean Software Development series by Mary & Tom Poppendieck.

[Update: 11:00 I have tweaked this article a bit for spelling, grammar, readability and completeness. I need a Definition of Done for my blog articles ;-) ]


Anonymous said…
Thank you for a great post. I have to develop training for Executive Leadership on Definition of Done and Delivered Value and this post with all the examples has really helped me get on the right track. Thank you.
Peter said…
Dear Anonymous,

Cool! I'm glad it helped! I'd love to hear more about your training and your audience. If you'd like to continue the conversation, you can contact me offline on the contact page.


Popular posts from this blog

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 sh…

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…