Definition of Done: esempio, checklist e workshop in Scrum
L’altro giorno ho preparato un workshop insieme a un collega. Ci siamo subito trovati d’accordo sul contenuto, l’unica cosa che mancava era una presentazione PowerPoint adatta. Per poter lavorare alla presentazione nel modo più efficiente possibile, l’abbiamo suddivisa per temi. Quando poi ci siamo seduti a discutere la bozza finita, è emerso un grosso problema: avevamo idee molto diverse su cosa caratterizzasse effettivamente una “bozza finita”.
Questo problema può presentarsi anche nei team Scrum agili. Dopo due settimane, il team raggiunge la fine dello sprint, ma c’è disaccordo sul fatto che l’incremento di prodotto sia già finito e possa essere spostato da “in progress” a “done”. Questo disaccordo porta a discussioni che a loro volta influenzano negativamente il clima del team. Per evitare queste discussioni e tutelare l’efficacia del lavoro di squadra, nel mondo Scrum esiste un artefatto chiamato “Definition of Done” (DoD).
Che cos’è la Definition of Done in Scrum?
La Definition of Done è l’accordo condiviso sulla qualità di un team Scrum. Descrive quali condizioni devono essere soddisfatte affinché un incremento sia considerato finito e utilizzabile. Non è un elenco personale di attività né un’ulteriore approvazione da parte di un singolo ruolo, ma uno standard trasparente per l’intero team.
Letteralmente, Definition of Done significa “definizione di finito”. Ciò significa che il team si accorda su ciò che deve essere fatto affinché una caratteristica sia considerata finita. In termini pratici, la Definition of Done può essere rappresentata come una sorta di lista di controllo che viene utilizzata durante lo sprint e soprattutto alla fine per verificare se sono stati soddisfatti determinati criteri di completamento. Per i team di sviluppo software, questi criteri possono essere, ad esempio, i seguenti:
Esempio di Definition of Done: checklist per team Scrum
Una Definition of Done pratica può contenere, per esempio, i seguenti criteri per un prodotto software:
- I criteri di accettazione e i requisiti funzionali sono soddisfatti.
- La documentazione è stata preparata.
- Il codice è completamente implementato e commentato.
- È stata effettuata una revisione del codice.
- I test automatizzati vengono eseguiti con successo; i bug rilevanti e i rischi di sicurezza sono stati affrontati.
- La modifica è integrata e può essere verificata in un ambiente vicino alla produzione.
- Monitoring, logging ed eventualmente le release notes sono presi in considerazione.
- L’incremento è utilizzabile e soddisfa lo standard di qualità del prodotto.
- …
Questo elenco è un esempio, non un modello universale. Una buona DoD protegge la qualità, resta applicabile al team in ogni Sprint e viene adattata quando cambiano il prodotto, i rischi o le condizioni tecniche.
Definition of Done non è la stessa cosa dell’impatto sul prodotto
Una Definition of Done risponde a una domanda importante: l’incremento soddisfa lo standard di qualità concordato ed è utilizzabile? Tuttavia non risponde automaticamente se la modifica nel mercato o presso il cliente ottenga l’effetto desiderato.
Per la pratica aiuta quindi distinguere tra tre livelli:
- Done: L’incremento soddisfa la Definition of Done e può essere utilizzato.
- Done-Done: La modifica è integrata, rilasciata e osservabile in esercizio.
- Impatto sul prodotto: Il feedback reale dei clienti mostra se la modifica risolve un problema rilevante e aumenta il valore del prodotto.
John Cutler descrive quindi il software come un sistema di servizi continuamente evoluto: le feature non sono edifici definitivi, ma mezzi temporanei per generare valore per il cliente. Leggi la sua prospettiva in The Work Is Never Done.
Gil Zilberfeld distingue inoltre tra diversi significati di «Done» – ad esempio quando sviluppo, test, rilascio o feedback dei clienti segnano ciascuno un diverso grado di completezza. La sua classificazione la trovi in The Definition of Done, Done-Done and Really Done.
Importante: «impatto sul prodotto» non dovrebbe essere semplicemente formulato come criterio aggiuntivo della DoD. Un team Scrum deve fornire un incremento utilizzabile; se esso produca l’effetto desiderato lo si vede in seguito attraverso Sprint Review, utilizzo e ulteriori cicli di apprendimento. Proprio questa separazione protegge la Definition of Done dal diventare una lista cumulativa irraggiungibile.
Come la Definition of Done si combina con altre pratiche Scrum efficaci, lo mostriamo nel nostro articolo Scrum Best Practices 2026.
Perché è importante la definizione di “Fatto”?
Che la definizione degli obiettivi sia di enorme importanza per le prestazioni non è un’intuizione nuova. La fissazione degli obiettivi è un argomento molto studiato in psicologia (cfr. Locke & Latham, 2006). È stato dimostrato che le prestazioni sono più elevate quando gli obiettivi sono il più possibile specifici e stimolanti senza sembrare irraggiungibili. La Definizione di Fatto non è, tuttavia, un metodo di definizione degli obiettivi (ma se deve essere utilizzata, è un metodo di definizione degli obiettivi). Supporto nella definizione degli obiettivi Se hai bisogno di aiuto, saremo felici di aiutarti); si tratta piuttosto di criteri che devono essere soddisfatti per raggiungere l’obiettivo.
Questi criteri sono importanti per creare un’intesa comune nel team. Una comprensione di ciò che ogni membro del team deve realizzare per raggiungere l’obiettivo comune. Si tratta quindi di prestazioni individuali che alla fine si sommano a quelle di un team.
Se consideriamo la questione della DoD dal punto di vista del proprietario del prodotto, i problemi diventano completamente diversi. Se non viene definito chiaramente quando un incremento di prodotto viene considerato finito, può verificarsi un disaccordo con il cliente quando gli viene presentato il prodotto. Se ciò accade e viene presentato un prodotto non finito, si blocca la possibilità di ricevere un feedback da parte del cliente.
Miglioramento continuo
Poiché la Definizione di Fatto non è un concetto statico e può e deve essere in continua evoluzione o cambiamento, offre al team anche l’opportunità di imparare. Se, al termine di uno sprint, il team si rende conto di non essere riuscito a soddisfare i criteri della Definizione di Fine, i membri del team possono modificare la Definizione di Fine per soddisfare le prestazioni effettive, oppure il team trae le conclusioni per lo sprint successivo e cambia il proprio modo di lavorare.
Prova subito Echometer e trova nuove ispirazioni per le tue retrospettive!
Queste riflessioni sulla Definizione di Fatto dovrebbero essere fatte dal team durante la retrospettiva. Possibile Articoli EchometerLe domande che si possono porre in fase di preparazione sono
Abbiamo delle chiare Definizioni di Fatto per i nostri requisiti.
Di solito so a che punto siamo nel raggiungimento dei nostri obiettivi comuni.
I miei obiettivi sono allineati con quelli dei miei colleghi.
Il team copre tutte le competenze necessarie per raggiungere il nostro obiettivo.
Non solo mettono in dubbio l’esistenza di una Definizione di Fatto nel team, ma anche la trasparenza, l’autonomia e la chiarezza dei ruoli all’interno del team.
Puoi trovare l’elenco completo degli articoli nel nostro sito Strumento retrò.
Come può il nostro team definire il fatto? Un esempio di workshop
Ti abbiamo mostrato cos’è una Definizione di Fatto e perché è importante per una collaborazione efficace nei team Scrum. Ma se il tuo team non ha ancora creato una DdT, probabilmente ti starai chiedendo come funziona.
In linea di principio, è importante che il team si prenda tutto il tempo necessario per preparare il documento. Alla fine, dovrebbe emergere un documento in cui ogni membro del team possa identificarsi e che non sia visto solo come un male necessario. Per questo motivo, consigliamo un formato simile a un workshop con lo Scrum Master come moderatore. Ogni membro del team deve pensare a quali criteri sono importanti per il completamento del prodotto e il team può poi riassumere questi pensieri. Analogamente, abbiamo sviluppato un formato di workshop per la definizione degli obiettivi. Dai un’occhiataper trovare idee per il tuo workshop sulla Definizione di Fatto!
La DoD completata può essere utilizzata nelle retrospettive, ad esempio sotto forma di semaforo della Definizione di Fatto:
- Scrivi di seguito i tuoi criteri per la definizione di Fatto.
- Disegna un quadrato rosso, uno giallo e uno verde accanto a ciascuno di essi.
- Per ogni elemento della Definizione di Fatto, ogni membro del team segna se è stato implementato bene, moderatamente bene o male nell’ultimo sprint.
- Discuti i tre con le menzioni più frequenti nell’area rossa.
- Se necessario, modifica la tua definizione di “Fatto”.
Conclusione - Finito?
Per concludere: nell’ambiente agile non esiste il concetto di “finito”. Fatto significa semplicemente che qualcosa è provvisoriamente finito, ma che possono e devono seguire ulteriori aggiustamenti e miglioramenti in qualsiasi momento. Questo è uno dei tanti aspetti belli del lavoro agile: il miglioramento continuo.
Particolarmente emozionante: a volte i punti sono “fatti” finché il cliente non si fa avanti e mette in discussione l’intera soluzione, scuotendo così le tue ipotesi sulle esigenze del cliente. In queste situazioni, diventa chiaro se il team ha davvero dato priorità ai vantaggi per il cliente rispetto ai progressi nel sistema dei ticket.
Una chiara definizione delle cose da fare può evitare conflitti e aumentare le tue prestazioni. Se ti interessano altri modi per raggiungere questo obiettivo, dai un’occhiata anche al nostro articolo sulla sorprendente verità che si cela dietro la mentalità agile Guarda. Oppure arricchisci le tue retrospettive tenendo conto delle ultime scoperte scientifiche in campo psicologico.
Proprio con questa promessa abbiamo sviluppato il nostro strumento retrò Echometer. Se ti interessa sapere come (e se) funziona Echometer, leggi il resoconto dell’esperienza di Holger con il nostro strumento:
Vuoi portare il tuo team a un nuovo livello di prestazioni? Il nostro Retro Tool può aiutarti a farlo. Ecco le esperienze di Holger:
Il resoconto dell’esperienza di Holger sullo Strumento Retro RemotoDomande frequenti sulla Definition of Done
Cosa deve contenere una Definition of Done?
In una Definition of Done rientrano tutti i criteri di qualità che un incremento deve soddisfare affinché sia utilizzabile. Esempi tipici sono criteri di accettazione soddisfatti, code review, test, verifica di sicurezza, documentazione e la possibilità tecnica di rilasciare. Quali punti valgano, lo decide il team in base al contesto del proprio prodotto.
Chi crea la Definition of Done in Scrum?
Il team Scrum sviluppa e mantiene insieme la Definition of Done. Non dovrebbe essere imposta da un singolo ruolo come lista di controllo. Le organizzazioni possono definire standard minimi, ma il team deve capirli e poterli applicare nella quotidianità.
Qual è la differenza tra Definition of Done e Definition of Ready?
La Definition of Done descrive quando un incremento è finito e utilizzabile. Una Definition of Ready può invece contenere criteri per la preparazione di un elemento di lavoro, ma non è un artefatto ufficiale di Scrum e non deve servire a spostare responsabilità o cicli di feedback.
Esempio pratico: la nostra Definition of Done interna in Echometer
Una Definition of Done non deve fermarsi al codice e ai test. Internamente, Echometer utilizza uno standard più ampio che, oltre alla funzionalità, tiene conto anche di UX, manutenibilità, osservabilità e preparazione del rilascio. L’esempio seguente mostra come un team possa rendere concreti e verificabili i propri criteri di qualità:
| Area | Criteri esemplificativi |
|---|---|
| Funzionalità | La funzionalità specificata funziona, i tipici casi limite sono stati verificati, non ci sono bug noti, le funzioni non ancora complete sono protette da un feature flag e i dati di utilizzo rilevanti vengono raccolti. |
| UX | Stati vuoti, stati di caricamento, autorizzazioni, gestione degli errori, localizzazione e presentazione responsive sono presi in considerazione. |
| Manutenibilità | Le Coding Guidelines e le convenzioni rilevanti sono rispettate, si è evitato codice inutile e debito tecnico lasciato intenzionalmente, e sono presenti informazioni importanti per monitoraggio e debug. |
| Deployment | La modifica è stata rilasciata in produzione o preparata consapevolmente tramite feature flag, le release notes sono state integrate e gli stakeholder interessati vengono informati se necessario. |
Questo esempio naturalmente non è un modello valido in generale. Potete però usarlo come base, arricchirlo con le vostre definizioni, verificarlo regolarmente e svilupparlo come documento vivo.
Fonti
Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x
