Week 47 Day 2: The Definition of Done Template -- Fill In the Blanks

The six fields: (1) What are the specific deliverables? (2) What quality standard applies? (3) What is explicitly included? (4) What is explicitly excluded? (5) How will completion be verified? (6) Who is the final approver? Each field forces a conversation that most leaders skip, and each skipped conversation becomes a source of rework later.

Here is the template with examples for each field. Field 1 -- Deliverables: list every concrete output the project produces. Not 'improve the dashboard' but 'updated dashboard with three new charts: revenue by segment, churn by cohort, and MRR trend. Each chart includes a 12-month trailing view and an export-to-CSV function.' The specificity eliminates the 'I thought you meant...' conversation. Field 2 -- Quality standard: define the level of polish, testing, and documentation required. 'Production-ready' means different things to different people. Be specific: 'Code reviewed by at least one peer, unit test coverage above 80% for new code, integration tests passing, load tested to 2x current peak traffic, deployed to staging and approved by Product Manager before production deploy.' Field 3 -- In scope: list what is included. This seems redundant with deliverables, but it is not. Deliverables are the outputs. Scope is the boundary of the work. 'In scope: dashboard charts, data pipeline for the three metrics, export functionality. In scope: performance optimization to keep page load under 2 seconds.' Field 4 -- Out of scope: list what is explicitly not included, especially the things that someone might reasonably assume are included. 'Out of scope: mobile-responsive design (that is a separate project in Q3), real-time data refresh (batch refresh every 6 hours is acceptable for this phase), user-level permissions on the dashboard (all authenticated users see all charts).' The out-of-scope list is often more valuable than the in-scope list because it prevents scope creep and eliminates the most common misunderstandings. Field 5 -- Verification method: how will you determine that the work is done? 'Done is verified by: (a) Product Manager reviews the staging deployment and approves, (b) QA completes the test plan with zero critical or high-severity bugs, (c) Lead engineer confirms performance targets are met.' Field 6 -- Final approver: who has the authority to declare the work complete? This prevents the 'I thought it was done but then someone else had feedback' loop. 'Final approver for this deliverable is [name]. Once [name] approves, the work is complete and the team moves to the next priority.' Print this template. Use it for every project kickoff. Over time, the team will internalize the six fields and apply them automatically, even without the template.

The six-field template implements what requirements engineering researchers call 'completeness dimensions' (Zave and Jackson, 1997) -- the principle that a specification is complete when it addresses: function (what the system does -- Field 1), quality (how well it does it -- Field 2), scope (boundary conditions -- Fields 3 and 4), verification (how completion is assessed -- Field 5), and authority (who decides -- Field 6). Their research found that incomplete specifications (missing one or more dimensions) were the single largest source of software project failure, responsible for more defects than coding errors, design errors, or testing failures. The explicit out-of-scope field (Field 4) addresses what Brooks (1975) calls the 'second-system effect' and what modern agile practitioners call 'scope creep' -- the tendency for project scope to expand as implementers discover adjacent work that 'should' be included. Research by Standish Group (2015) in the CHAOS Report found that scope changes were the leading cause of project delay (affecting 52% of delayed projects), and that projects with explicit scope exclusions experienced 30% fewer scope changes than projects that defined only inclusions. The final approver field (Field 6) implements what organizational design researchers call 'decision rights clarity' (Jensen and Meckling, 1992) -- their work demonstrates that ambiguity about who has the authority to make a decision (in this case, the decision that work is complete) produces either decision paralysis (no one declares it done) or decision conflict (multiple stakeholders provide conflicting assessments of completeness).