The Three Faces of Done

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.

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.

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?

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!”

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?

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: