The Three Faces of Done

External Quality — Building the right thing. 

We could call this “Customer’s Intent.”

• 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

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

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

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? 

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

• 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?

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: