Marco MerlinoIn questo articolo si approfondisce laDefinition of Readycome pratica utile a distinguere un’idea ancora confusa da un’attività realmente eseguibile.
Molte difficoltà nei team Agile non nascono durante lo sviluppo, ma prima, quando il lavoro entra nello sprint senza essere sufficientemente chiarito.
La DoR, insieme alla Definition of Done, protegge sia l’ingresso sia l’uscita dello sprint.
In conclusione, la Definition of Ready rende visibile il confine tra desiderio, priorità e lavoro realmente realizzabile.
Quando il problema non è eseguire, ma iniziare nel modo sbagliato
In molte organizzazioni Agile, una parte significativa delle difficoltà non nasce durante lo sviluppo, maprima che lo sviluppo inizi davvero.
Il team entra in sprint con attività apparentemente chiare, user story già inserite nel backlog, priorità formalmente definite e obiettivi dichiarati. Tutto sembra pronto. Eppure, dopo pochi giorni, emergono domande rimaste senza risposta, requisiti ambigui, dipendenze non considerate, criteri di accettazione incompleti, vincoli tecnici non esplicitati.
A quel punto il lavoro rallenta.
Gli sviluppatori chiedono chiarimenti.
Il Product Owner deve ricostruire il contesto.
Gli stakeholder intervengono con precisazioni tardive.
Lo sprint perde fluidità.
La pianificazione si rivela meno solida di quanto sembrasse.
Questo fenomeno è molto comune. E spesso viene interpretato come un problema di esecuzione, di comunicazione interna o di capacità del team. In realtà, molte volte il problema è più semplice e più profondo:il lavoro è stato avviato prima di essere realmente pronto.
LaDefinition of Readynasce esattamente per affrontare questa criticità. È uno strumento apparentemente operativo, ma con una forte implicazione manageriale: aiuta il team a distinguere tra un’idea ancora confusa e un’attività realmente eseguibile.
In altre parole, definisce il confine tra ciò che può entrare in lavorazione e ciò che deve ancora essere chiarito, raffinato, discusso o validato.
Il rischio nascosto di un backlog apparentemente ordinato
Uno degli equivoci più diffusi nelle organizzazioni che adottano Scrum è pensare che un backlog ben popolato sia automaticamente un backlog utile.
Un Product Backlog può contenere molte user story, essere organizzato per priorità, riportare stime, tag, epic, dipendenze e scadenze. Può apparire ordinato e gestibile. Ma questo non significa che gli elementi al suo interno siano pronti per essere sviluppati.
La qualità di un backlog non si misura dalla sua quantità, né dalla sua forma esteriore. Si misura dalla capacità di trasformare le intenzioni dell’organizzazione in lavoro comprensibile, realizzabile e verificabile.
È qui che emerge il vero valore della Definition of Ready:impedire che l’incertezza venga trasferita dallo spazio della discussione allo spazio dell’esecuzione.
Quando un elemento non sufficientemente chiaro entra in sprint, l’incertezza non scompare. Si sposta semplicemente sul team. E quando l’incertezza arriva nel momento dell’esecuzione, diventa più costosa, più urgente e più difficile da gestire.
Un requisito ambiguo discusso durante il refinement è un normale elemento di lavoro.
Lo stesso requisito scoperto durante lo sprint diventa un blocco operativo.
Questa differenza è cruciale.
In un’organizzazione matura, non tutto ciò che è importante è automaticamente pronto. Alcune idee possono essere strategiche, urgenti o desiderate dal management, ma non per questo immediatamente eseguibili. La Definition of Ready permette di rendere visibile questa distinzione, proteggendo il team da un errore molto frequente:confondere la priorità con la maturità del lavoro.
Che cos’è davvero la Definition of Ready
La Definition of Ready può essere descritta come un insieme di condizioni che un elemento del Product Backlog deve soddisfare per poter essere preso in carico dal team durante uno sprint.
Questa definizione, però, rischia di essere troppo riduttiva se viene interpretata solo come una checklist tecnica.
La Definition of Ready non è semplicemente una lista di controllo. È un accordo operativo tra Product Owner, team di sviluppo e stakeholder sul significato concreto della parola “pronto”.
Nel linguaggio quotidiano delle organizzazioni, infatti, “pronto” può voler dire molte cose diverse.
Per uno stakeholder, una funzionalità è pronta quando è stata richiesta con sufficiente urgenza.
Il Product Owner, può considerarla pronta quando è stata inserita nel backlog e collegata a un obiettivo di prodotto.
Per il team tecnico, invece, è pronta solo quando esistono informazioni sufficienti per comprenderla, stimarla, svilupparla e verificarla.
La Definition of Ready serve proprio a evitare questa ambiguità.
Rende esplicito ciò che altrimenti resterebbe implicito.
Stabilisce che una user story non è pronta solo perché esiste. È pronta quando il team comprende il valore atteso, conosce il contesto, dispone di criteri di accettazione sufficientemente chiari, ha identificato le principali dipendenze e ritiene che l’attività possa essere completata entro lo sprint senza dover ricostruire da zero il significato del lavoro.
Ready non significa perfetto
Uno dei rischi principali nell’adozione della Definition of Ready è trasformarla in un meccanismo burocratico. Quando questo accade, il team finisce per usare la DoR come una barriera rigida, una sorta di cancello formale attraverso cui il lavoro può passare solo se ogni dettaglio è stato definito in anticipo.
Questo approccio tradisce lo spirito Agile.
La Definition of Ready non deve riportare l’organizzazione verso una logica waterfall, in cui tutto deve essere analizzato e documentato prima di iniziare. Non serve a eliminare ogni incertezza, né a produrre requisiti perfetti. Serve piuttosto a garantire che l’incertezza residua sia compatibile con il lavoro da svolgere.
Ready non significa completo in ogni dettaglio. Significa sufficientemente chiaro per iniziare in modo responsabile.
Questa distinzione è fondamentale.
In contesti complessi, pretendere di avere tutte le risposte prima di iniziare è illusorio. Ma iniziare senza aver chiarito le domande essenziali è altrettanto pericoloso. La Definition of Ready si colloca esattamente in questo equilibrio: non bloccare l’apprendimento, ma evitare che il team parta da una confusione strutturale.
Una buona Definition of Ready non irrigidisce il lavoro. Lo rende più fluido.
Non rallenta lo sprint. Riduce i blocchi durante lo sprint.
Non limita la responsabilità del Product Owner. La rende più efficace.
La relazione tra Definition of Ready e Product Backlog Refinement
Per comprendere la Definition of Ready, è necessario collegarla alProduct Backlog Refinement.
Il refinement è il momento in cui il team lavora sulla qualità degli elementi futuri del backlog. Non è una riunione amministrativa, né un passaggio obbligato per assegnare stime. È uno spazio di comprensione condivisa.
Durante il refinement, il team esplora le user story, chiarisce il valore atteso, discute scenari, identifica vincoli, formula domande, valuta dipendenze e riduce progressivamente l’incertezza. La Definition of Ready rappresenta il criterio con cui il team può dire: questo elemento è sufficientemente maturo per essere considerato in uno sprint planning.
Senza refinement, la Definition of Ready diventa teorica.
Senza Definition of Ready, il refinement rischia di diventare conversazione senza soglia decisionale.
Le due pratiche funzionano insieme.
Il refinement è il processo attraverso cui il lavoro viene preparato.
La Definition of Ready è il criterio attraverso cui il team riconosce che quella preparazione è sufficiente.
Questa relazione è particolarmente importante nelle organizzazioni in cui il backlog tende a essere alimentato da molte fonti: vendite, operations, direzione, customer care, compliance, marketing, clienti diretti. In questi casi, la pressione sul Product Owner può essere molto alta, e il rischio è trasformare il backlog in un contenitore di richieste più che in uno strumento di governo del prodotto.
La Definition of Ready aiuta a riportare ordine, ma non attraverso il controllo burocratico. Lo fa attraverso una domanda semplice e potente:
abbiamo capito abbastanza per iniziare a lavorare bene?
La Definition of Ready come strumento di protezione del team
In Scrum si parla spesso di commitment, focus, trasparenza, ispezione e adattamento. Ma nella pratica quotidiana molti team faticano a mantenere concentrazione perché vengono continuamente esposti a lavoro immaturo.
Una user story poco chiara non è solo un elemento incompleto del backlog. È un generatore di interruzioni.
Produce domande durante lo sprint.
Costringe a rinegoziare il perimetro.
Apre discussioni tardive con gli stakeholder.
Introduce ambiguità nei criteri di accettazione.
Aumenta il rischio di rilavorazioni.
In questo senso, la Definition of Ready è anche uno strumento di protezione del team.
Non protegge il team dal cambiamento, perché il cambiamento resta parte integrante del lavoro Agile. Lo protegge dalla confusione non gestita. Protegge la capacità del team di concentrarsi su un obiettivo di sprint realistico, riducendo il numero di decisioni che non dovrebbero essere prese durante la fase esecutiva.
Questo punto è particolarmente rilevante per il management.
Quando un team non completa ciò che era stato pianificato, la prima reazione è spesso interrogarsi sulla produttività. Ma prima di valutare la performance del team, bisognerebbe valutare la qualità del lavoro che gli è stato affidato.
Non si può chiedere prevedibilità a un team alimentato da ambiguità.
La Definition of Ready rende questa ambiguità visibile. E proprio per questo può generare tensioni. Perché obbliga l’organizzazione a riconoscere che alcune richieste non sono pronte, anche se sono urgenti, desiderate o politicamente rilevanti.
Che cosa dovrebbe contenere una buona Definition of Ready
Ogni team dovrebbe costruire la propria Definition of Ready in base al contesto, al prodotto, al livello di maturità e alla complessità tecnica. Non esiste una formula universale valida per tutte le organizzazioni.
Tuttavia, una Definition of Ready efficace tende a coprire alcune dimensioni ricorrenti.
Una user story dovrebbe avere un obiettivo comprensibile, collegato a un valore di business o a un bisogno utente. Dovrebbe essere sufficientemente piccola da poter essere completata all’interno dello sprint, oppure almeno scomponibile in parti gestibili ed essere corredata da criteri di accettazione chiari, capaci di rendere verificabile il risultato atteso. Sarebbe necessario avesse le principali dipendenze note, soprattutto se coinvolge altri team, sistemi esterni, fornitori o decisioni ancora aperte. Dovrebbe essere stimabile dal team, non perché la stima sia perfetta, ma perché il livello di comprensione è sufficiente per ragionare sull’impegno necessario.
In alcuni contesti, può essere utile includere anche elementi legati alla compliance, alla sicurezza, alla disponibilità dei dati, all’esperienza utente o all’impatto architetturale. In altri, soprattutto nei prodotti digitali, può diventare importante verificare che esista un minimo di validazione dell’esigenza, evitando di trasformare ogni richiesta interna in lavoro immediato.
Il punto, però, non è costruire una lista lunga. Anzi, una Definition of Ready troppo pesante rischia di diventare controproducente.
La migliore Definition of Ready è quella che rende il lavoro più chiaro senza renderlo più burocratico.
Il caso concreto: la piattaforma customer portal di Ferrolinea
Per comprendere l’impatto della Definition of Ready, immaginiamo il caso di un’azienda ipotetica, ma molto realistica, che chiameremoFerrolinea.
Ferrolinea è un’azienda industriale che produce componenti metallici per il settore ferroviario e automotive. Negli ultimi anni ha avviato un programma di digitalizzazione dei servizi post-vendita, con l’obiettivo di offrire ai clienti un customer portal attraverso cui consultare documentazione tecnica, verificare lo stato degli ordini, aprire richieste di supporto e scaricare certificazioni di qualità.
Il progetto viene affidato a un team Scrum composto da sviluppatori, un UX designer, un tester, uno Scrum Master e un Product Owner proveniente dall’area business.
All’inizio il progetto sembra procedere bene. Il backlog è ricco, gli stakeholder sono coinvolti, la direzione considera il portale un’iniziativa strategica. Tuttavia, dopo i primi sprint emergono segnali di difficoltà.
Molte user story entrano in sprint con descrizioni troppo generiche. Alcune dipendono da dati non ancora disponibili nei sistemi ERP. Altre richiedono decisioni da parte dell’ufficio qualità o del reparto legale. In alcuni casi i criteri di accettazione vengono chiariti solo quando lo sviluppo è già iniziato.
Il team completa meno lavoro del previsto. Non perché lavori poco, ma perché trascorre troppo tempo a ricostruire il significato delle attività.
Durante le retrospettive emergono frasi ricorrenti: “non era chiaro cosa volesse davvero il cliente”, “mancavano le regole di business”, “abbiamo scoperto troppo tardi che il dato non era disponibile”, “la story sembrava piccola, ma nascondeva molte dipendenze”.
Il problema diventa evidente: Ferrolinea non ha un problema di sprint execution. Ha un problema dipreparazione del lavoro.
L’introduzione della Definition of Ready
Dopo alcune retrospettive, il team decide di introdurre una Definition of Ready condivisa.
La scelta viene fatta con attenzione, evitando di trasformarla in un meccanismo punitivo verso il Product Owner o verso gli stakeholder. L’obiettivo dichiarato non è “bloccare” il lavoro, ma aumentare la qualità del lavoro che entra nello sprint.
Il team organizza una sessione dedicata con Product Owner, Scrum Master, rappresentanti del business, IT e qualità. Vengono analizzate le user story che negli sprint precedenti avevano generato più blocchi e rilavorazioni. Da questa analisi emergono pattern molto chiari.
Le story relative alla documentazione tecnica fallivano quando non era definito il livello di autorizzazione degli utenti. Quelle sullo stato degli ordini diventavano problematiche quando non era chiaro quale sistema fosse la fonte dati ufficiale. Le story sulle certificazioni si bloccavano quando mancavano regole condivise su formato, validità e responsabilità di pubblicazione.
Da questi elementi nasce una Definition of Ready pragmatica, costruita non su principi astratti ma sui problemi reali del team.
Una user story può entrare nello sprint solo se il valore atteso è chiaro, i criteri di accettazione sono comprensibili, le fonti dati sono identificate, le principali dipendenze sono esplicitate e il team ritiene che il lavoro sia stimabile e completabile nel ciclo previsto.
Non è una rivoluzione metodologica. È una soglia minima di maturità.
Eppure produce un cambiamento immediato.
Il cambiamento prodotto nel lavoro quotidiano
Nei refinement successivi, il team inizia a usare la Definition of Ready come strumento di conversazione.
Quando una user story non soddisfa i criteri, non viene semplicemente respinta. Viene riportata allo spazio corretto: quello dell’approfondimento. Il Product Owner sa quali informazioni recuperare. Gli stakeholder capiscono quali decisioni devono prendere. Il team tecnico può esplicitare prima i rischi invece di scoprirli durante lo sprint.
Il customer portal di Ferrolinea continua a evolvere, ma il modo in cui il lavoro arriva al team cambia profondamente.
Le discussioni si spostano prima.
Le dipendenze vengono intercettate prima.
Le ambiguità diventano visibili prima.
Gli sprint diventano più stabili.
Nel giro di alcuni cicli, il team registra una riduzione significativa delle attività bloccate durante lo sprint. Anche la relazione tra Product Owner e stakeholder migliora, perché la Definition of Ready offre un linguaggio condiviso per distinguere tra desideri, richieste e lavoro eseguibile.
Il punto più interessante è che la Definition of Ready non riduce la flessibilità. Al contrario, aumenta la capacità del team di rispondere al cambiamento perché diminuisce la quantità di confusione introdotta nel momento sbagliato.
Un team che parte da lavoro più chiaro non diventa meno Agile. Diventa più capace di adattarsi.
Il ruolo del Product Owner: da raccoglitore di richieste a curatore della qualità del backlog
L’introduzione della Definition of Ready modifica anche il ruolo del Product Owner.
In molte organizzazioni, il Product Owner viene spinto a comportarsi come un collettore di richieste. Riceve input da più parti, li traduce in user story, li ordina nel backlog e cerca di mediare tra aspettative diverse. Ma questo ruolo, se interpretato in modo troppo passivo, rischia di indebolire la qualità del prodotto.
La Definition of Ready aiuta il Product Owner a esercitare una responsabilità più matura:curare la qualità del backlog, non solo la sua priorità.
Prioritizzare un backlog immaturo non basta. Significa ordinare elementi che potrebbero non essere ancora compresi, validati o realizzabili. La vera responsabilità del Product Owner è garantire che il team lavori su elementi coerenti con gli obiettivi di prodotto e sufficientemente preparati per essere eseguiti.
Questo non significa che il Product Owner debba avere tutte le risposte. Significa che deve orchestrare le conversazioni necessarie affinché le risposte essenziali emergano prima dello sprint.
In questo senso, la Definition of Ready non limita il Product Owner. Lo rafforza.
Gli offre un criterio oggettivo per negoziare con gli stakeholder, spiegare perché una richiesta urgente non può entrare immediatamente in sviluppo e proteggere la coerenza del prodotto rispetto alla pressione dell’organizzazione.
Definition of Ready e Definition of Done: due confini diversi
Per comprendere pienamente la Definition of Ready, è utile confrontarla con la più notaDefinition of Done.
La Definition of Done stabilisce quando un elemento può essere considerato completato. Riguarda la qualità dell’output: codice sviluppato, test eseguiti, documentazione aggiornata, criteri soddisfatti, incremento potenzialmente rilasciabile.
La Definition of Ready, invece, riguarda la qualità dell’input. Stabilisce quando un elemento può essere considerato pronto per essere lavorato.
Sono due confini diversi, entrambi essenziali.
La Definition of Ready protegge l’ingresso nello sprint.
La Definition of Done protegge l’uscita dallo sprint.
La prima riduce l’ambiguità prima dell’esecuzione.
La seconda garantisce qualità prima del completamento.
Quando una squadra utilizza solo la Definition of Done, può comunque produrre incrementi di buona qualità partendo da elementi poco chiari, ma con maggiore fatica, più conversazioni tardive e più rischio di rilavorazione. Quando utilizza anche una buona Definition of Ready, il flusso diventa più coerente.
La qualità del risultato dipende anche dalla qualità del punto di partenza.
I principali errori da evitare
Il primo errore consiste nel trasformare la Definition of Ready in una barriera burocratica. Se ogni user story deve essere definita in modo eccessivo prima di entrare in sprint, il team perde agilità e l’organizzazione ricade in una logica di analisi preventiva troppo pesante.
Il secondo errore è usare la DoR come strumento difensivo. Quando il team la utilizza per respingere tutto ciò che è incerto, invece di collaborare per chiarirlo, la pratica diventa una fonte di frizione.
Il terzo errore è imporre una Definition of Ready dall’alto. Ogni team deve partecipare alla sua definizione, perché solo chi lavora quotidianamente sul prodotto conosce davvero quali condizioni rendono un’attività eseguibile.
Il quarto errore è non aggiornarla mai. Una Definition of Ready efficace evolve insieme al team, al prodotto e al contesto. All’inizio può essere semplice e concentrata su chiarezza, criteri di accettazione e dimensione delle story. In seguito può includere aspetti più sofisticati, come dati, sicurezza, compliance, UX, architettura o validazione dell’ipotesi.
Una Definition of Ready immobile rischia di diventare irrilevante.
Perché la Definition of Ready è anche uno strumento di governance
A prima vista, la Definition of Ready sembra una pratica interna al team Scrum. In realtà, ha una rilevanza più ampia.
Ogni organizzazione ha un problema di governo della domanda. Le richieste arrivano da clienti, mercato, direzione, funzioni interne, vincoli normativi, urgenze operative. Non tutte hanno lo stesso valore, non tutte sono ugualmente mature, non tutte possono diventare immediatamente lavoro.
La Definition of Ready aiuta a costruire una disciplina nella gestione della domanda.
Non decide da sola cosa sia importante, ma aiuta a capire cosa sia effettivamente lavorabile. La strategia non può essere sostituita, ma impedisce che la strategia venga tradotta in attività confuse. Non elimina il confronto con gli stakeholder, ma lo rende più trasparente.
In questo senso, la DoR diventa uno strumento di governance leggera. Non aggiunge livelli autorizzativi, ma introduce un principio di responsabilità condivisa:
se vogliamo che il team lavori bene, dobbiamo alimentarlo con lavoro sufficientemente maturo.
Questo principio è tanto semplice quanto spesso disatteso.
Molte organizzazioni chiedono ai team velocità, prevedibilità e qualità, ma forniscono input instabili, incompleti e contraddittori. La Definition of Ready rende visibile questa incoerenza e permette di correggerla.
Quando non usarla in modo rigido
È importante chiarire che la Definition of Ready non deve diventare una regola assoluta applicata senza discernimento.
Esistono situazioni in cui il team può decidere consapevolmente di lavorare su elementi non completamente pronti. Può accadere in contesti di forte urgenza, in sperimentazioni rapide, in spike tecnici, in attività esplorative o in momenti in cui l’obiettivo dello sprint è proprio ridurre l’incertezza.
La differenza è la consapevolezza.
Un conto è introdurre lavoro immaturo nello sprint senza rendersene conto.
Un altro conto è decidere esplicitamente che una certa attività serve a chiarire un’incertezza.
Nel secondo caso non si tratta di violare la Definition of Ready, ma di usare correttamente l’empirismo Agile. L’importante è non confondere un’attività esplorativa con una user story pronta per la delivery.
La DoR non serve a impedire l’apprendimento. Serve a evitare che l’apprendimento venga mascherato da esecuzione.
Questa frase riassume bene il senso della pratica.
Rendere visibile il confine tra desiderio e lavoro
La Definition of Ready è una delle pratiche più sottovalutate nelle organizzazioni Agile.
Forse perché appare troppo semplice.
Perché non ha il fascino dei framework più complessi.
Forse perché costringe a guardare un punto scomodo: la qualità del lavoro prima che arrivi al team.
Eppure, proprio qui si gioca una parte importante della maturità organizzativa.
Un team non può essere efficace se ogni sprint diventa il luogo in cui chiarire ciò che avrebbe dovuto essere compreso prima. Non può essere prevedibile se riceve input ambigui. Non può essere realmente autonomo se dipende continuamente da decisioni esterne non prese.
La Definition of Ready non risolve tutti questi problemi, ma li rende visibili. E quando un problema diventa visibile, può finalmente essere gestito.
Il caso di Ferrolinea mostra come una pratica semplice possa cambiare profondamente il modo in cui un’organizzazione alimenta il proprio processo di sviluppo. Non attraverso più controllo, ma attraverso più chiarezza. Meno documentazione, ma migliori conversazioni. Non attraverso più rigidità, ma attraverso una maggiore responsabilità condivisa.
In ultima analisi, la Definition of Ready aiuta le organizzazioni a superare una confusione molto diffusa: pensare che ciò che è urgente sia automaticamente pronto, che ciò che è desiderato sia automaticamente eseguibile, che ciò che è scritto nel backlog sia automaticamente compreso.
Ma tra un’idea e il lavoro reale esiste un confine invisibile.
La Definition of Ready serve a renderlo esplicito.
Perché il vero problema, spesso, non è la lentezza con cui i team lavorano.
È la leggerezza con cui l’organizzazione decide che qualcosa è pronto per essere fatto.
