Coming close matters only in horseshoes and hand grenades…
I’ve had the topic of “Definition of Done” on my to do list for quite some time. And I’ve started many a draft post. Only never to get past started… ironic.
One of the teams I coach recently found the need to iterate on their DoD. Their need reminded me of a great summary from Scrum Shortcuts without Cutting Corners:
All tradesmen know ‘If you don’t know what Done looks like you will never finish.’ Knowing what ‘Done’ looks like is so important that it forms a recognizable pattern of thinking. Knowing ‘Done’ must be constantly enforced and reinforced. There are some simple questions you can ask to understand ‘Done’ when working on a Story or painting a wall, and they can be summarized by: “If it were ‘Done’, what would it look like to you?” When a good understanding of ‘Done’ is missing, projects both big and small fail or go sideways.
I shared with the team an approach that I learned from Dan Rawsthorne’s great book: Exploring Scrum.
- A DoD doesn’t need to be perfect. We don’t need to spend an eternity deliberating over what is in, what is out. GEFN is well, good enough for now.
- A DoD should be approached and applied at different levels: task, story, feature, and release.
- A DoD is never done. Nothing is cast in stone because it needs to evolve over time, as informed by reality.
A Sample Definition of Done
Referencing how all the things fit together, here’s the working list of what Done means to one team:
Task (e.g, Git To Do List Item – doable in an ideal day)
- Unit Test Coverage
- Lint Checks Passing
- Peer Code Review
- Merged and non-breaking CI tests
Story – (User Focused) – Git Issue Card
- Documentation Updated
- Passing QA Smoke tests
- Delivered Business Value
Feature or a Collection of Features – (Epic or multiple Epics)
- Integration Tests
- High-Level Documentation Updated
- Product owner acceptance/sign off
Release (Potentially shippable state) – Git Repo Milestone
- Deploy scripts modified/tested
- Load Tests
- Training of CS on new functionality/features
So when I hit “publish” I’ll have achieved Done for this post, at least for now.
There are many existing resources for additional reading, approaches to defining and refining your own DoD’s. Here are a few:
- Rally Software: Defining Done
- Mitch Lacey & Associates: Definition of Done
- Scrum Alliance: Definition of Done: A Reference
- Scrum Alliance: How Do We Know When We Are Done?
- SolutionsIQ: Good DoD
- SolutionsIQ: What is the Definition of Done (DoD) in Agile?
- Luis Gonçalves: Definition of Done in Scrum (DoD)-What can you do to Mature It?