Who Owns the Definition of Done (DoD)?

Tom Breur

30 July 2017

In Scrum there is a central role for the “Definition of Done” (DoD) – in itself a nebulous concept. Software is never really “done”, until you stop working on it. And that of course only happens after you decommission it. Alas, in Scrum we rely on this notion of “done” that typically signifies when we are ready to promote code to production.

In order to guarantee a sustainable pace of development (the eighth principle of the Agile Manifesto), a feature that is presented as “done” should meet minimal criteria of completion. The Scrum team decides what those completion criteria should be. Some topics that often seem to appear are: fully tested, peer reviewed, documented, coded to team standards, code is properly commented, feature has been publicized in end-user manuals, help files released, code refactored, etc. As those norms grow within each Scrum team, they embody a shared standard to make code “shippable” – even if it doesn’t get deployed, yet. Many teams document their DoD criteria in checklists that they run by every item in the backlog, before moving it to “done.”

Note that this Definition of Done does not require the Product Owner to accept this feature. Hopefully, there has been ample communication bandwidth (PO always available), so that any questions arising after the Sprint Planning could be answered immediately. Still, misunderstandings happen, and developers are free –even encouraged– to take liberties in how to fulfill the User Story. It’s that empowerment and required entrepreneurial spirit that helps a team go faster. During the Sprint demo, the Product Owner can pass his final verdict.

Within the Scrum process, a precise delineation of “done” is rather important: it determines what has and has not been completed within the Sprint (iteration), and deemed of appropriate quality (but not over engineered, not “gold plated”). Over time, and especially during retrospectives, teams may find that some rework, documentation, or refactoring (still) needs to be done on previously released features. When that happens, they may decide to “tighten up” (further explicate) their Definition of Done. Just like many other Agile practices it is actually a good idea to iterate on it…