In questo articolo voglio spiegare cosa sono Definition of Done e Definition of Ready, quali sono le differenze e come le utilizzo nei progetti reali.

Collegherò inoltre questi concetti ad alcuni principi più ampi di qualità che utilizzo come riferimento all’interno del SAFe Framework .

Cosa sono Definition of Done e Definition of Ready?

Entrambe le definizioni aiutano il team a creare criteri più oggettivi per il flusso di lavoro.

Io le riassumo in modo molto semplice:

Definition of Ready risponde: “Possiamo iniziare?”

Definition of Done risponde: “Possiamo dire davvero di aver finito?”

La prima protegge l’ingresso di una task nel processo.

La seconda protegge la sua uscita.

Quando entrambe funzionano correttamente, il team condivide una comprensione molto più chiara di ciò che deve esistere prima di iniziare e di ciò che significa realmente terminare.

Cos'è la Definition of Ready (DoR)?

La Definition of Ready (DoR) stabilisce le condizioni minime che mi aspetto che una task soddisfi prima di iniziare la sua esecuzione.

Non significa cercare di scoprire assolutamente tutto prima di iniziare.

I progetti contengono sempre incertezza.

Ma esiste una grande differenza tra lavorare con un certo livello di incertezza e iniziare una task che nessuno comprende abbastanza bene.

A seconda del progetto, una Definition of Ready può aiutarci a verificare domande come:

• È chiaro il problema che dobbiamo risolvere?
• L’obiettivo della task è definito?
• Sappiamo quale risultato ci aspettiamo?
• I criteri di accettazione sono documentati?
• Le principali dipendenze sono state identificate?
• Esistono informazioni tecniche sufficienti?
• I flussi principali e alternativi sono chiari?
• Il team dispone di informazioni sufficienti per stimare il lavoro?
• I dubbi critici sono stati risolti?

Uso una regola pratica:

Se durante il refinement il team non comprende ancora cosa deve essere fatto, probabilmente la task non è ancora Ready.

Cos'è la Definition of Done (DoD)?

La Definition of Done (DoD) stabilisce le condizioni necessarie affinché una task o una consegna possa essere considerata realmente completata.

Il suo obiettivo è evitare situazioni come queste:

• Lo sviluppo è terminato, ma i test non sono ancora stati completati;
• I test sono terminati, ma manca una validazione;
• La funzionalità è pronta, ma la documentazione non lo è;
• La task appare come Done sulla board, ma deve ancora tornare al team.

In tutti questi casi sorge la stessa domanda:

La consegna è davvero Done?

A seconda del progetto, la mia Definition of Done può includere:

• Criteri di accettazione soddisfatti;
• Validazione funzionale completata;
• Test eseguiti con successo;
• Test automatizzati superati;
• Revisione tecnica completata;
• Documentazione aggiornata;
• Standard tecnici e di prodotto rispettati;
• Accettazione formale della consegna quando necessaria.

L’obiettivo è fare in modo che tutto il team condivida una comprensione ragionevolmente oggettiva di ciò che significa dire:

“Abbiamo finito.”

Differenze tra Definition of Ready e Definition of Done

Per me, la differenza può essere riassunta così:

La Definition of Ready protegge l’inizio del lavoro.

La Definition of Done protegge la sua conclusione.

La DoR cerca di evitare che una task inizi prima di avere le condizioni necessarie per essere eseguita.

La DoD cerca di evitare che una task esca dal processo prima di soddisfare le condizioni che il team considera necessarie per una consegna completa.

Quando la Definition of Ready è debole, normalmente mi aspetto di trovare:

• Più dubbi durante l’esecuzione;
• Più interruzioni;
• Più tempo di attesa;
• Stime meno affidabili;
• Maggiore rischio di rilavorazione.

Quando la Definition of Done è debole, posso invece trovare:

• Task chiuse troppo presto;
• Problemi scoperti dopo la consegna;
• Task riaperte;
• Qualità inconsistente;
• Rilavorazioni dopo quella che avrebbe dovuto essere la conclusione.

Definition of Ready, Definition of Done e criteri di accettazione non sono la stessa cosa

Un altro punto importante è non trattare DoR, DoD e criteri di accettazione come se fossero esattamente la stessa cosa.

Io li separo in questo modo:

• Definition of Ready: quali condizioni deve soddisfare la task prima di iniziare?
• Criteri di accettazione: quali condizioni specifiche deve soddisfare quella particolare consegna?
• Definition of Done: quali condizioni devono essere soddisfatte affinché il lavoro possa essere considerato terminato?

I criteri di accettazione possono cambiare da una task all’altra.

DoR e DoD aiutano invece a creare uno standard condiviso sulle condizioni di ingresso e uscita del lavoro.

Esempio di Definition of Ready

Nei miei progetti, per creare chiarezza e migliorare la documentazione, utilizzo spesso un tripode formato da:

• PO — responsabile delle aspettative di business;
• UI — responsabile dei flussi e dell’esperienza attesa;
• Tech Leader — responsabile dell’orientamento tecnico.

Per preparare una task:

• UI documenta il flusso atteso e i flussi alternativi;
• PO documenta ciò che è atteso come risultato di business;
• Tech Leader documenta le principali indicazioni tecniche.

Perché utilizzo questo modello?

Perché non parto mai dal presupposto che tutte le persone che entrano in un progetto possiedano già tutta la conoscenza di business, prodotto e tecnologia necessaria per prendere qualsiasi decisione.

All’inizio, alcune persone diventano naturalmente punti di riferimento.

Con il tempo, l’obiettivo è fare in modo che il resto del team accumuli conoscenza e autonomia sufficienti per dipendere sempre meno da loro.

Anche il refinement fa parte della mia Definition of Ready

Quando il team analizza una task durante il refinement e compaiono domande importanti alle quali nessuno sa rispondere, non cerco semplicemente di spingerla nello sprint.

Quelle domande rappresentano informazioni mancanti che devono essere chiarite.

La task torna quindi in refinement fino a raggiungere un livello di chiarezza sufficiente.

Non cerco una documentazione perfetta.

Cerco di ridurre i dubbi prevedibili prima che si trasformino in blocchi durante l’esecuzione.

Nel contenuto originale questo approccio è già collegato al refinement, al TDD e al BDD: se il team non comprende la task, questa non dovrebbe ancora entrare nello sprint. :contentReference[oaicite:1]{index=1}

Esempio di Definition of Done

Per la Definition of Done utilizzo anche questi professionisti per validare formalmente la consegna quando necessario.

Inoltre, considero i test una delle principali barriere di sicurezza.

A seconda del progetto, la mia DoD può includere:

• Criteri di accettazione soddisfatti;
• Validazione del PO;
• Validazione UI quando necessaria;
• Peer review o revisione tecnica;
• Casi di test eseguiti;
• Test unitari automatizzati superati;
• Documentazione aggiornata;
• Standard del progetto rispettati.

L’obiettivo è creare una barriera di sicurezza.

Se una condizione critica non è ancora soddisfatta, la consegna non dovrebbe essere trattata come conclusa.

Perché i team abbandonano Definition of Ready e Definition of Done?

Se queste definizioni aiutano così tanto, perché scompaiono da così tanti progetti?

Ho alcune ipotesi:

• Mancanza di esperienza da parte dei leader del team;
• Difficoltà nel convincere altre persone sull’importanza delle definizioni;
• Mancanza di autorità o influenza dei leader;
• Progetti già in ritardo;
• Progetti di innovazione con un maggiore livello di incertezza;
• Prodotti e progetti senza un processo chiaramente definito.

C’è un comportamento che osservo frequentemente.

Quando un progetto è in ritardo, iniziamo a eliminare le attività che apparentemente consumano tempo.

Riduciamo i refinement.

Iniziamo task prima che siano sufficientemente chiare.

Riduciamo le validazioni.

L’obiettivo è accelerare.

Ma se queste decisioni generano più dubbi, errori e rilavorazioni, finiamo per perdere proprio il tempo che stavamo cercando di risparmiare.

Quando sospetto che il problema sia più profondo, cerco prima di capire la causa radice. Puoi trovare qui un altro articolo in cui spiego come trovare la causa radice dei problemi di un progetto .

Prima di cambiare DoR e DoD, capisci chi deve essere coinvolto

Quando il problema è legato alla mancanza di influenza o autorità, non cercherei semplicemente di imporre una nuova Definition of Ready o Definition of Done.

Prima allineerei queste definizioni con gli stakeholder che hanno maggiore influenza e impatto sul progetto.

Ho scritto più nel dettaglio su questo argomento in: Come usare la Stakeholder Matrix per aumentare la tua influenza e migliorare la comunicazione del progetto .

Definition of Done e Definition of Ready fanno parte di una discussione più ampia sulla qualità

Per me, DoR e DoD non sono concetti isolati.

Fanno parte di una discussione più ampia sulla qualità del processo che trasforma una necessità in una consegna.

Per questo mi piace collegarli ad alcuni dei concetti di Built-In Quality di SAFe .

Nel contenuto originale, questa discussione comprende già shift learning left, pair programming, peer review, collective ownership, competenze T-shaped, standard e automazione del workflow. :contentReference[oaicite:2]{index=2}

Shift learning left

Lo sviluppo di prodotti contiene sempre scenari che il team scoprirà solo mentre il lavoro avanza.

Lo stesso vale per le singole task.

Ma più tardi scopriamo un dubbio, una dipendenza o un problema importante, più difficile e costoso può diventare correggerlo.

Questo può avere conseguenze su scope, qualità, schedule e costi.

Per questo motivo cerco di anticipare domande e validazioni ogni volta che è possibile.

Pair programming e peer review

Pair programming e peer review possono portare un’altra prospettiva sul modo in cui una consegna viene costruita.

Ma esiste anche una realtà:

Se due persone lavorano sulla stessa task, non stanno lavorando su due task diverse.

La qualità ha un costo.

E quasi tutti i progetti hanno pressione per consegnare più velocemente.

Per questo queste pratiche devono essere analizzate in base al rischio, al contesto e alla capacità disponibile.

Il testo originale affrontava già direttamente questo compromesso tra capacità e qualità. :contentReference[oaicite:3]{index=3}

Collective ownership e competenze T-shaped

Un altro obiettivo importante è evitare che tutta la conoscenza critica rimanga concentrata in una sola persona.

All’inizio di un progetto, o quando entrano nuovi professionisti, la conoscenza delle regole di business, delle decisioni precedenti e dell’architettura può essere ancora molto bassa.

Questa conoscenza deve essere costruita e distribuita progressivamente.

L’obiettivo non è che tutti sappiano assolutamente tutto.

L’obiettivo è ridurre dipendenze che potrebbero trasformarsi in rischi per il progetto.

Standard e Definition of Done

Ogni professionista possiede i propri pattern di lavoro.

Quando questi pattern vengono condivisi e documentati, possono diventare standard del progetto.

E questo è direttamente collegato alla Definition of Done.

Se ogni persona ha un’interpretazione diversa di ciò che significa una consegna di qualità, lo stato Done perde valore.

Nel processo originale, test case e test unitari automatizzati erano già utilizzati come parte della Definition of Done proprio per creare una barriera di sicurezza prima della produzione. :contentReference[oaicite:4]{index=4}

Automazione del workflow

I workflow spesso contengono passaggi manuali tra diversi professionisti.

Ogni passaggio può generare attesa.

Il team può inoltre perdere tempo effettuando ispezioni manuali o cercando componenti che esistono già.

Automatizzare parti di questo processo può aiutare a ridurre tempi, costi e attività manuali.

DoR e DoD influenzano anche produttività e prevedibilità

Quando una task inizia senza sufficiente chiarezza, il tempo perso non scompare.

Riappare durante l’esecuzione sotto forma di:

• Domande;
• Messaggi;
• Riunioni;
• Attese;
• Rilavorazioni;
• Nuove stime;
• Ritardi.

Allo stesso modo, quando una task viene considerata Done troppo presto, parte del lavoro ritorna successivamente sotto forma di correzione.

Per questo non considero Definition of Ready e Definition of Done soltanto controlli di qualità.

Aiutano anche a proteggere il flusso, la produttività e la prevedibilità del progetto.

Come Saint Jude aiuta a identificare problemi di Ready e Done

Jira, Azure DevOps, ClickUp, Monday.com, Asana e altre piattaforme contengono una grande quantità di informazioni sulle task e su come il lavoro si muove.

Saint Jude funziona come uno strato di intelligence sopra questi dati.

L’obiettivo è aiutare project manager, PMO e leader a individuare segnali come:

• Task che entrano in esecuzione senza informazioni sufficienti;
• Stime che non corrispondono all’esecuzione reale;
• Attività che rimangono troppo tempo in determinati stati;
• Blocchi ricorrenti;
• Task riaperte o restituite per correzioni;
• Rilavorazioni frequenti;
• Ritardi che possono compromettere lo schedule;
• Impatto dei problemi di qualità su costi e produttività.

Non si tratta di trasformare Definition of Ready e Definition of Done in burocrazia.

Si tratta di capire se le regole definite dal team stanno realmente aiutando il lavoro a fluire meglio oppure se gli stessi problemi continuano a ripetersi.

Definition of Ready e Definition of Done non dovrebbero esistere soltanto in un documento

Creare una DoR e una DoD non risolve nulla se diventano due checklist dimenticate in una pagina di documentazione.

Devono far parte del modo in cui il team lavora.

La Definition of Ready dovrebbe evitare che task senza le condizioni minime entrino in esecuzione.

La Definition of Done dovrebbe impedire che lavoro incompleto venga considerato concluso.

Ed entrambe devono evolvere man mano che il team impara.

Definition of Ready stabilisce quando possiamo iniziare. Definition of Done stabilisce quando possiamo dire davvero di aver finito.

Se vuoi capire dove task poco chiare, rilavorazioni, blocchi e problemi di qualità stanno influenzando tempi, produttività o costi, scopri Saint Jude e i suoi moduli di Project Intelligence .

E nel tuo team? Definition of Ready e Definition of Done fanno davvero parte del processo oppure compaiono soltanto quando qualcuno si ricorda che esistono?

A presto!

Erik Scaranello