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?
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:
We could call this “Customer’s Intent.”
So many questions! Can you verify this as a customer or even as a (non-technical) 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!”
What if you are not doing software? How does this apply? Just ask your team:
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?
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:
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 😉 ]