Week 28 Day 7: Assignment: Write a Definition of Done for Your Team's Most Common Deliverable

Identify the type of work your team delivers most frequently -- a feature, a report, a design, a campaign, a release. Write a Definition of Done for that specific type of deliverable. Share it with the team and agree on it before the next project starts.

Here is the step-by-step process. Step one: identify your most common deliverable type. For engineering teams, this is usually a feature or a bug fix. For design teams, it is usually a design spec or a prototype. For product teams, it is usually a requirements document or a user story. Pick the one your team does most often. Step two: gather input from every role that touches the deliverable. Schedule a 30-minute meeting with one representative from each role: creator, reviewer, consumer. Ask each person: 'What does done mean to you for this type of work?' Write down every answer. Step three: consolidate the answers into a checklist using the principles from Day 4. Every item must be binary (yes/no), specific (no ambiguous language), and essential (you would not ship without it). Aim for 8-12 items. Fewer than 8 usually means you missed something. More than 12 usually means you included aspirational items. Step four: calibrate using the tiered approach from Day 6. Is this deliverable type always high-stakes, or does the required quality vary? If it varies, create two or three tier levels with different checklist items. Step five: pilot the Definition of Done for two weeks. Apply it to every deliverable of that type. After the pilot, retrospect: did any items cause false stops (blocking work that should have shipped)? Did any gaps allow work to ship that should have been caught? Adjust accordingly. Step six: add the finalized Definition of Done to your Leadership Operating Manual under 'Quality Standards.' Reference it in project kickoffs and use it as the acceptance criteria in code reviews and design reviews.

The collaborative Definition of Done creation process implements what Schein (2004) calls 'humble inquiry' -- the practice of asking genuine questions to surface the assumptions and expectations of each team role before codifying them into shared standards. Research by Edmondson (2012) on 'teaming' found that the process of creating shared agreements is often more valuable than the agreements themselves, because the conversation surfaces latent disagreements that would otherwise manifest as downstream conflicts. The 8-12 item guideline draws on research by Sweller (1988) on 'cognitive load theory,' which demonstrates that working memory can effectively process approximately 7 (+/- 2) items simultaneously. A Definition of Done with more than 12 items exceeds the reviewer's cognitive capacity for simultaneous evaluation, leading to selective attention and inconsistent application. The pilot-and-retrospective methodology is supported by implementation science research (Proctor, Powell, and McMillen, 2013), which identifies 'iterative testing' as one of five essential strategies for sustainable practice change. Their research found that interventions refined through piloting had 40-60% higher long-term adoption rates than interventions implemented without iterative refinement.