Definition of Done: Cos’è e Come Utilizzarla

Galen Low

on Jun 19, 2026

Ho imparato che la maggior parte dei dibattiti sulla definizione di done non riguarda il lavoro in sé, ma le aspettative. Ecco come creare una definition of done che allinei qualità, fiducia e consegna.

Key Takeaways

Coerenza della Qualità: Stabilire una definition of done condivisa previene confusioni e migliora la qualità del lavoro all'interno del team.

Previsioni Migliorate: Una definition chiara aiuta a prevedere meglio la velocità e a pianificare meglio i progetti.

Trappole Comuni: Evita di rendere la definition troppo dettagliata o di non applicarla; entrambe le cose possono causare problemi.

Passi Pratici: L'articolo indica passi concreti per creare una definition of done efficace per team agile.

La definizione di done (DoD) è lo standard condiviso che determina quando un lavoro è realmente completo. Aiuta a prevenire lacune di qualità, rifacimenti e sorprese proprio alla fine dello sprint. Ho visto team di sviluppo perdere fiducia, mancare le scadenze e creare conflitti inutili perché ognuno aveva un’interpretazione diversa di "completato".

In questa guida imparerai come creare una definition of done che allinei il tuo team agile, migliori la prevedibilità e rafforzi la qualità, con esempi pratici, modelli ed errori comuni da evitare.

Cos'è la Definition of Done?

La definition of done è un insieme formale e condiviso di criteri che un item del product backlog o un incremento deve soddisfare prima che il team lo consideri completo e potenzialmente rilasciabile. Pensala come il contratto di qualità che il tuo team si impegna a rispettare per ogni lavoro, indipendentemente da dimensione o complessità.

Ecco le caratteristiche principali di una buona definition of done:

Trasparenza: Tutti nel team e tra gli stakeholder chiave possono consultarla, leggerla e farvi riferimento in qualsiasi momento.
Misurabile: Ogni criterio è binario. Il lavoro lo soddisfa oppure no, ma le soglie che scegli per i criteri quantitativi meritano un’attenta valutazione. Un obiettivo di code coverage all’80% è binario nell’applicazione, ma la scelta dell’80% invece del 70% o del 90% è una decisione che dovresti prendere consapevolmente.
Universalmente compresa: Ogni membro dello Scrum team deve essere in grado di interpretare ogni punto allo stesso modo.
Applicata con coerenza: Lo stesso elenco viene applicato a ogni deliverable e item del product backlog.
Raggiungibile entro uno sprint: I criteri dovrebbero essere realistici, in modo che il team possa raggiungerli in uno sprint o iterazione.

Nei progetti di sviluppo software, solitamente sono gli sviluppatori a possedere la definition of done perché sono loro a dovervi aderire. Detto questo, anche il product owner e lo scrum master dovrebbero contribuire.

Se la tua organizzazione ha già standard specifici per la definition of done, ogni Scrum team deve seguirli come base minima. I team possono sempre aggiungere criteri più restrittivi, ma non scendere sotto il livello organizzativo.

Perché la Definition of Done è Importante

Una definition of done chiara è importante perché impedisce che lavori parzialmente completati passino inosservati e fornisce uno standard di qualità condiviso.

Ecco altri motivi per cui una definition of done condivisa è fondamentale:

Agisce come barriera di qualità integrata: Ogni item deve superare la stessa soglia prima di essere considerato completo. Questo impedisce che lavori non finiti entrino nell’incremento di prodotto e si accumulino come debito tecnico.
Elimina l’ambiguità: Quando il team condivide una sola definizione, non si creano situazioni in cui definizioni contrastanti influenzano velocità o qualità del lavoro. Una definition of done condivisa significa meno conflitti, meno sorprese e demo più pulite.
Migliora la previsione: Quando "fatto" significa sempre la stessa cosa ad ogni sprint, puoi prevedere la velocity con sicurezza e programmare release senza aggiungere margini per il rifacimento.
Costruisce fiducia negli stakeholder: Quando product owner, leadership e stakeholder esterni vedono che il tuo team applica uno standard di qualità chiaro, si fidano dei vostri deliverable.
Previene il caos nell’integrazione: Se lavori in modo che il team debba integrare il proprio lavoro in un incremento condiviso, una comprensione comune della definition of done è la base per incrementi consistenti e rilasciabili.

Come Creare una Definition of Done

Ecco i passi chiave per creare una definition of done efficace.

Analizza il tuo attuale flusso di lavoro: Traccia ogni fase che il tuo lavoro attraversa prima di arrivare in produzione. Parla con sviluppatori, tester, designer e chiunque altro sia coinvolto nel processo. Scoprirai passaggi di qualità informali che dovrebbero essere formalizzati.
Identifica i criteri di qualità irrinunciabili: Decidi quali attività devono essere eseguite per ogni singolo lavoro. Queste di solito includono la revisione del codice, il testing automatico, l’aggiornamento della documentazione e le scansioni di sicurezza. Sii onesto su ciò che stai attualmente saltando.
Redigi la checklist in modo collaborativo: Coinvolgi tutto il team e crea la checklist insieme utilizzando una lavagna o un documento condiviso dove ognuno può aggiungere, discutere e perfezionare gli elementi in tempo reale. Una definition of done adottata con il consenso del gruppo resiste meglio sotto pressione rispetto ad una imposta superando obiezioni a maggioranza.
Valida rispetto agli standard dell’organizzazione: Incrocia la tua bozza con eventuali policy di qualità aziendali, requisiti normativi o standard di settore che il tuo prodotto deve rispettare. Se la tua organizzazione ha già una definition of done di base, parti da lì e migliorala.
Rendila visibile: Pubblica la definition of done dove il team lavora ogni giorno. Potrebbe essere un poster appeso al muro, un messaggio fissato su Slack o un pannello nello strumento di gestione progetti.
Impegnati a farla rispettare: Una definition of done che viene disattesa quando ci sono scadenze imminenti è peggiore di non averne alcuna, perché crea una falsa percezione di qualità.

Esempi di Definition of Done

Ecco alcuni esempi di definition of done per diversi tipi di progetto:

Definition of Done per progetti di sviluppo software

I progetti software affrontano una vasta gamma di rischi qualitativi: bug, vulnerabilità di sicurezza, regressioni di performance e problemi di integrazione. La definition of done per un team software deve coprire l’intero percorso dal codice fino allo stato pronto per il rilascio.

Potrebbe essere composta da:

Tutto il codice scritto e revisionato da almeno un altro sviluppatore
Test unitari superati con copertura almeno al livello concordato
Test di integrazione superati nella pipeline CI/CD
Nessun bug aperto con gravità critica o alta
Documentazione tecnica aggiornata in base alle modifiche
Codice unito sul branch principale
Product owner ha revisionato e accettato il lavoro
Performance soddisfatta secondo le soglie concordate

Definition of Done per progetti di marketing

Il lavoro di marketing spesso presenta aspetti legati a conformità, branding e misurazione che lo differenziano dallo sviluppo software.

Ecco come potrebbe apparire la definition of done per un progetto marketing:

Contenuto revisionato e approvato dal team legale
Checklist SEO completata, inclusi meta description, testo alternativo e link interni
Tutti gli asset caricati nel CMS e formattati correttamente
Tracciamento analitico configurato e verificato nell’ambiente di staging
Testo finale corretto da un secondo membro del team
Checklist di lancio campagna approvata dal team lead

Definition of Done per progetti di design

I team di design devono usare la definition of done per colmare il divario tra l’intento creativo e la consegna tecnica. Senza una, i design arrivano allo sviluppo incompleti, con dettagli mancanti, comportamento responsivo non validato o carenze di accessibilità scoperte troppo tardi.

Ecco un esempio di definition of done per un progetto di design:

Design revisionato secondo gli standard di accessibilità WCAG 2.2
File di consegna preparato sull’apposito strumento con tutte specifiche, asset e annotazioni
Approvazione e documentazione della firma dei portatori d’interesse
Componenti del design system aggiornati in caso di nuovi pattern
Comportamento responsivo validato alle breakpoint concordate

Definition of Done vs. Acceptance Criteria

La definition of done è il vostro standard di qualità a livello di team, mentre gli acceptance criteria sono i requisiti funzionali a livello di funzionalità.

Pensa alla definizione di fatto come alla base che si applica universalmente, mentre i criteri di accettazione sono specifici per ogni backlog di sprint o singolo elemento del product backlog. Un elemento del product backlog è considerato completo quando soddisfa sia i suoi criteri di accettazione sia la definizione di fatto della squadra.

Aspetto	Definizione di fatto	Criteri di accettazione
Ambito	Si applica a ogni elemento del product backlog e incremento	Specifico per una singola user story o elemento del product backlog
Titolarità	Di proprietà degli sviluppatori, con contributi dall’intero team Scrum	Scritto dal product owner o con il suo coinvolgimento
Specificità	Standard qualitativi generali per tutto il lavoro	Requisiti funzionali dettagliati per una singola attività
Frequenza di cambiamento	Cambia raramente; viene aggiornato durante le retrospettive di sprint	Cambia a ogni nuova user story
Punto di verifica	Controllato prima che ogni elemento sia considerato completo	Verificato durante la revisione della storia o nell’accettazione

Errori Comuni e Trappole

Ecco alcuni errori comuni da evitare quando si creano le definizioni di fatto:

Saltare elementi per andare più veloci: I team sotto pressione spesso eliminano criteri come la revisione della sicurezza, i test di accessibilità o la documentazione. Questo crea debito tecnico nascosto che emergerà più tardi sotto forma di bug, lavoro aggiuntivo o problemi di conformità.
Checklist troppo dettagliata: Una definizione di fatto eccessivamente dettagliata diventa un compito burocratico. Se la tua checklist ha 30 punti e gli sviluppatori passano più tempo a spuntare caselle che a scrivere software, hai esagerato. Sii abbastanza specifico da essere significativo, ma sufficientemente generico da restare pratico.
Modificare la definizione di fatto per ogni storia: Lo scopo della definizione di fatto è garantire coerenza. Le condizioni specifiche della funzionalità appartengono ai criteri di accettazione (ad esempio, ai criteri di accettazione tipo dato-quando-allora), non alla definizione di fatto.
Non rivederla mai: La definizione di fatto deve evolversi man mano che le tue pratiche maturano, i tuoi strumenti cambiano o il prodotto cresce. Ti suggerisco di rivederla durante le retrospettive almeno una volta a trimestre, e di aggiornarla quando il team individua lacune o difficoltà.
Non farla rispettare: Una definizione che viene ignorata quando qualcuno di importante lo chiede è inutile. Il compito dello Scrum Master è proteggerla, anche quando un stakeholder vuole rilasciare qualcosa che non rispetta gli standard. Se i criteri vengono spesso ignorati, il team perde fiducia nello standard e smette di prenderlo sul serio.
Confondere “fatto” con “rilasciato”: La definizione di fatto stabilisce se un incremento è rilasciabile, non se sia stato effettivamente rilasciato. Un elemento del product backlog può essere definito fatto senza essere stato distribuito. Non aggiungere "rilasciato in produzione" alla tua definizione di fatto a meno che il tuo team non gestisca davvero tutto il processo di rilascio dall’inizio alla fine.
Dimenticare di consultarla: Molti team hanno tecnicamente una definizione di fatto, ma se nessuno l’ha letta negli ultimi sei mesi, non funziona come standard di qualità.

Cosa Succede Ora?

Migliora i tuoi processi agili e i modi di lavorare con strumenti pratici, modelli e approfondimenti esperti tramite una membership DPM gratuita, e rafforza i sistemi che aiutano i team a offrire costantemente lavoro di qualità.