Definition of Done (DoD) e Definition of Ready (DoR)

Definition of Done e Definition of Ready sono due accordi espliciti del team che eliminano l'ambiguità sui termini più usati e più fraintesi del project management: "pronto" e "fatto".

Senza DoD e DoR, "fatto" significa cose diverse per persone diverse. E ogni differenza è un conflitto in attesa di esplodere.

Definition of Done (DoD)

Cos'è

Una lista di criteri condivisi che un task/feature/incremento deve soddisfare per essere considerato completato.

In Scrum è un commitment ufficiale dell'Increment (Scrum Guide 2020): senza DoD, lo sprint non può concludersi.

A cosa serve

• Elimina ambiguità su "ho finito"
• Garantisce qualità minima e prevenibilità
• Riduce rilavorazioni e bug post-rilascio
• Allinea PO, dev, QA, ops
• Base per stime realistiche (se la DoD include test e doc, lo stimi)

Esempio: DoD di una user story (software)

✓ Codice scritto e committato sul branch corretto
✓ Code review approvata da almeno 1 altro dev
✓ Unit test scritti, copertura ≥ 80% sui nuovi file
✓ Test di integrazione passati
✓ Test E2E su flusso happy path passati
✓ Documentazione tecnica aggiornata (README, ADR, OpenAPI)
✓ Documentazione utente aggiornata (se rilevante)
✓ Conformità linter / formatter
✓ Nessun warning di sicurezza (SAST)
✓ Performance regression test passati
✓ Deployato in ambiente di staging
✓ Acceptance criteria della user story verificati dal PO
✓ Accessibilità WCAG AA verificata (se UI)
✓ Localizzazione IT + EN (se UI)

Esempio: DoD di un deliverable (marketing)

✓ Brief approvato dal PM
✓ Contenuto scritto e proofreading interno
✓ Revisione legale (se claim regolamentati)
✓ Approvazione brand
✓ Asset visuali finalizzati e nel DAM aziendale
✓ Tracking analytics configurato
✓ Pubblicato sui canali previsti
✓ Email di lancio interno inviata
✓ KPI baseline registrati

Definition of Ready (DoR)

Cos'è

I criteri che un item del backlog deve soddisfare per essere pronto a entrare in lavorazione (es. essere preso in uno sprint).

Se la DoD risponde a "quando posso dire fatto?", la DoR risponde a "quando posso iniziare?"

A cosa serve

• Evita di iniziare lavoro a metà, con requisiti vaghi
• Riduce blocchi mid-sprint ("ah, mi serve l'API di X...")
• Forza il refinement del backlog prima dello Sprint Planning
• Migliora la prevedibilità

Esempio: DoR per una user story

✓ Storia scritta in formato "Come [user], voglio [azione], per [valore]"
✓ Acceptance criteria definiti e chiari
✓ Stima (story points o ore) condivisa dal team
✓ Dipendenze identificate (e idealmente risolte)
✓ Design / wireframe disponibile (se UI)
✓ API contract definito (se backend)
✓ Dati di test disponibili (se applicabile)
✓ Nessun bloccante esterno aperto
✓ Cabe in uno sprint (se più grande → spezzare)

Le 3 C delle user story (Ron Jeffries)

Una user story ben fatta segue le 3 C:

DoR garantisce le 3 C soddisfatte; DoD garantisce la Confirmation verificata.

DoD ad ogni livello

La DoD può (e dovrebbe) essere stratificata:

Acceptance Criteria vs DoD

Spesso confusi. La differenza:

Una storia è "Done" quando soddisfa sia gli acceptance criteria sia la DoD del team.

Formato "Given-When-Then" per Acceptance Criteria

Stile Gherkin (Behavior-Driven Development):

Given [contesto / precondizione]
When  [azione dell'utente]
Then  [risultato atteso]

Esempio:

Scenario: Login con credenziali valide
  Given un utente registrato con email "marco@example.com"
  When  inserisce email e password corrette
  Then  viene reindirizzato alla dashboard
  And   vede il proprio nome in alto a destra

✓ Pro: chiaro, traducibile in test automatizzati. ✕ Contro: verboso, può sembrare burocratico.

Anti-pattern

DoD

• ✕ DoD non scritta: ognuno ne ha una mentale, e sono diverse
• ✕ DoD aspirazionale: "100% test coverage" se siete al 30% → non la rispetterete mai
• ✕ DoD imposta dall'alto: senza buy-in del team, non viene applicata
• ✕ Mai aggiornata: cresce il prodotto, la DoD deve crescere
• ✕ "Quasi fatto": una storia è fatta o non lo è. Non esiste "Done* (con asterisco)"

DoR

• ✕ DoR perfezionista: aspetti che tutto sia perfetto → niente entra mai in sprint
• ✕ DoR come scusa: "non era ready, perciò non lo abbiamo fatto" → cultura del rinvio
• ✕ DoR rigida in early stage: una startup ha bisogno di flessibilità

Bilanciare DoR e DoD

DoR troppo larga + DoD troppo stretta = il team annega in storie che non finisce mai. DoR troppo stretta + DoD troppo larga = il team consegna velocemente ma il prodotto è inaffidabile.

Equilibrio sano: DoR garantisce che si possa iniziare; DoD garantisce che si stia consegnando vero valore di qualità.

Come costruirle col team

Workshop di 1h, all'inizio di un nuovo progetto o di un nuovo team:

1. Brainstorming silenzioso (10 min): cosa per te significa "fatto"?
2. Clustering (10 min): raggruppa gli item simili
3. Discussione (20 min): cosa è veramente necessario? cosa è opzionale?
4. Voto (5 min): dot voting per priorità
5. Stesura (10 min): scrivi la versione 1.0
6. Commit (5 min): tutti d'accordo? bene. Vive in un posto visibile

Ripeti ogni 2-3 mesi: la DoD/DoR evolve col team e col prodotto.

Esempi reali di team maturi

Team Spotify (years ago):

• DoR include "design Figma approvato + dati di telemetria definiti"
• DoD include "experiment behind flag + tracking event live + post-launch review schedulata"

Team Amazon:

• DoR include "PR/FAQ scritto (working backwards)"
• DoD include "OE review + alarms configurati + runbook"

Nota il pattern: aziende mature lavorano backward dalla qualità che vogliono in produzione.

DoD/DoR fuori dal software

I principi si applicano ovunque ci sia produzione di output ripetuti:

Collegamenti

• Scrum — DoD è uno dei 3 commitment Scrum
• Task — la DoD chiude i task
• Success Criteria — analogo a livello progetto
• Kanban — la DoD è la policy della colonna "Done"
• Retrospective — momento ideale per evolvere DoD/DoR
• Esecuzione — fase d'uso quotidiano
• User Stories — acceptance criteria sono parte delle story