Does my team need a Definition of Done?

You have one, even if it’s not written down. Writing it down can be a useful step to make sure that everyone has the same expectations, and to surface any points of misalignment early.

A Definition of Done is a set of criteria to define when work is finished. Very literally, it defines what needs to be finished in order to drag a ticket from In Progress to Finished.

Within your team, it describes the quality and completeness of work you expect from yourselves. When working with external teams - or contractors - it’s useful as a contract or interface between teams. It’s clear what’s the responsibility of your team, because it will be in the DoD.

DoD doesn’t always need to be synonymous with “shippable to prod”, but most times it is.

I use this very quick and dirty template as a starting point for defining DoD. It’s easy to remember. You’ve finished something: TADA! 🎉

T: Tests. Must have suitable automated test coverage (unit and integration) and pass any security scans and GitHub Checks.

A: Alerts. New code must be instrumented with alerts/monitoring so we know it's working as expected. If there are alerts that will trigger a PagerDuty incident, a runbook must be linked to the alert or incident type.

D: Documentation. Internal and external documentation must be completed.

A: Analytics. All new user behaviors need to be instrumented with analytics events so we can track how customers are using the feature.

You might want to augment this with other security requirements, linting, code review standards, etc.

Definition of Done has deep roots in agile and scrum, so there’s no shortage of resources or opinions on what it should or shouldn’t be. Here’s an example that gets more specific than my template above. Enjoy!