Definition of Done (DoD)

tl;dr: How will we know if we’re done (with the right level of quality) on this thing?

Are we there yet?

Coming close matters only in horseshoes and hand grenades…

Agile Definition of Done DoD

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

Definition of Done for Agile Development
From Rawsthorne, Dan; Shimp, Doug (2011-08-14). Exploring Scrum: the Fundamentals

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)

  • Implemented
  • 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
  • Metrics/Monitoring
  • Training of CS on new functionality/features

The End

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:

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top