Upholding Standards with a Definition of Done
You may have encountered different forms of a “definition of done” or seen various implementations of such a document. The Scrum.org Scrum Glossary defines this as:
A formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released.
The core intent of a definition of done is simple: if a change “meets the quality measures,” it can be released. A definition of done can be used to provide a very simple indicator of whether a change to your application can be shipped to your users. That moment of merging a change to the trunk and triggering an automated deployment can be tense and fraught. To counteract these feelings, it can be useful to remind yourself of what “done” really means.
Defining Done
Nothing is ever truly done. Software is never perfect. Bugs are inevitable.
The Cult of Done Manifesto is a motivational resource for getting things done, whatever your task may be. Point 12 rings particularly true for serverless software engineering: “If you have an idea and publish it on the internet, that counts as a ghost of done.” This can be interpreted as defining “done” as getting something in front of your users. It doesn’t matter if that thing is complete and polished; what matters most is that it is now gathering usage data that can be used to inform improvements.
Shipping imperfect features should never be confused with promoting unilateral, careless engineering. Software engineering should always be a social activity and the needs of your users held in the highest regard. But the best software is always software that is being used.
If you don’t ship your software you will never know if it really works in production, under real traffic and with all the other code and variables out there in the wild. A definition of done checklist will give you the right confidence to ship: not so much in whether your change will work but in that you’ll know if it isn’t working.
Go forth and release the ghosts of done!
Answering the following questions will allow you to pragmatically decide whether a change can be released or not. Document them somewhere accessible to your engineers and attach this document to any artifacts associated with the work being undertaken, such as pull requests or task tickets:
How will the quality of this code be measured?
This will be down to your team to decide. You could link quality to service level objectives (explored in Chapter 8), application performance metrics, or business metrics.
How will this code be released to production users?
It might be released immediately upon deployment, rolled out with a blue/green strategy, or constitute a dark release where it is available in production but not publicized to users.
How will you know if this code is broken before production?
What pre-deployment tests are in place, and what aspects or failure modes of the code do they cover?
How will you know if this code is broken in production?
What alerts are in place, and under what conditions will these alerts be triggered?
How will you be able to debug this code if it breaks in production?
Is distributed tracing enabled for this component? What logs are available? Is there a runbook for triaging potential or known failures?
How will this code recover from failure in production?
How is this code tolerant of faults, either its own or others? What recovery mechanisms are in place (for example, dead letter queues and retries)?