Week 28 Day 1: Most Teams Argue About Completion Because They Never Defined It

Ask five people on any team 'is this project done?' and you will get five different answers. The designer says it is done because the mockups are approved. The developer says it is not done because the edge cases are not tested. The product manager says it is done because the feature works in the demo. The QA engineer says it is not done because there are three open bugs. The manager says it is done because the deadline has passed. Nobody is wrong. They are each applying a different definition of done -- and the team never agreed on a shared one.

The absence of a shared Definition of Done creates a specific pattern of dysfunction that I have seen on every team that lacks one. Stage one: the work is 'completed' by the person doing it, using their personal standard. They feel good about it. Stage two: someone else reviews the work and finds gaps. The reviewer is not wrong -- the gaps are real. But the person who completed the work feels ambushed because they met their own standard. Stage three: the argument. The person who did the work says 'you never told me that was required.' The reviewer says 'it should have been obvious.' Both are right, which is why the argument has no resolution. Stage four: rework. The person goes back and addresses the gaps, but now the rework feels like punishment rather than process. Their motivation drops. The trust between them and the reviewer drops. Stage five: the pattern repeats on the next project because nobody defined done before starting. I estimated once that my team spent 15-20% of total engineering time on rework caused by undefined completion criteria. Not technical debt. Not scope creep. Just the gap between one person's definition of done and another's. A 30-minute conversation at the start of each project would have eliminated most of it.

The Definition of Done (DoD) concept originated in Agile software development (Schwaber and Sutherland, 2020) as a formal mechanism for eliminating the ambiguity that leads to the conflict pattern described in level_2. The Scrum Guide defines the DoD as 'a formal description of the state of the Increment when it meets the quality measures required for the product' and specifies that it must be shared across the entire team. Research by Hoda, Noble, and Marshall (2013) on Agile team practices found that teams with explicit Definitions of Done had 35% less rework than teams without them, and that the definition's value came not from the document itself but from the conversation required to create it -- the process of negotiating shared standards forced the team to surface and resolve differing expectations. The five-person disagreement pattern in level_1 illustrates what Thompson and Fine (1999) call 'shared cognition failure' -- the organizational condition where co-workers operate with different mental models of the same task. Research by Mathieu, Heffner, Goodwin, Salas, and Cannon-Bowers (2000) on 'shared mental models and team performance' found that the degree of mental model similarity among team members predicted team process quality (r = 0.44) and team performance (r = 0.36), with completion criteria being the specific dimension showing the largest variance.