Definition of Ready: perché ogni Scrum Team dovrebbe averla.
Lo so, nella Scrum Guide non c’è menzione alcuna della “Definition of Ready”, l’unica definizione che fa ufficialmente parte di Scrum è la “Definition of Done”, ma… citando la Scrum Guide:
Gli elementi del Product Backlog che possono essere completati (“Done”) dallo Scrum Team all’interno di uno Sprint sono considerati pronti per la selezione in un evento di Sprint Planning. Di solito acquisiscono questo grado di trasparenza dopo le attività di Refinement.
— Scrum Guide 2020 —
Quindi dobbiamo capire cosa significa “pronto” per il nostro team e come possiamo metterci d’accordo sul fatto che un determinato elemento del backlog sia“pronto” per la selezione durante lo Sprint Planning. Diventa quindi utile avere una “Definition of Ready” condivisa. Ed è per questo che, anche se non se ne parla direttamente nella Scrum Guide, molti Scrum Team maturi la usano e la mantengono viva.
Facciamo un passo indietro: cosa significa “Pronto”?
La precedente citazione della Scrum Guide afferma: Gli elementi del Product Backlog di solito acquisiscono questo grado di trasparenza dopo le attività di Refinement. Non voglio entrare nei dettagli del processo di Refinement del Product Backlog, ma vale la pena fare un’altra citazione dalla Scrum Guide che lo descrive brevemente:
Il Refinement del Product Backlog è l’atto di scomporre e definire ulteriormente gli elementi del Product Backlog in elementi più piccoli e più precisi. Si tratta di un’attività continuativa per aggiungere dettagli, come la descrizione, l’ordine e la dimensione.
Il concetto chiave è che perfezioniamo gli elementi per renderli “pronti”, cosicché, quando arriva il momento dello Sprint Planning, possiamo essere sicuri che elementi in cima al nostro backlog siano “pronti” per essere lavorati e per essere spostati nello Sprint Backlog. In altre parole, vogliamo che quegli elementi siano “lavorabili”. Una volta che un elemento è stato inserito nello Sprint Backlog, non dovrebbe essere necessario (idealmente) raccogliere altre informazioni al riguardo. Dovremmo già sapere quali sono i requisiti chiave e come possiamo testarlo e implementarlo.
Il che sembra semplicemente buon senso, giusto? Perché allora dovremmo avere una definizione formale per una cosa così basilare? Perché molte cose sembrano essere ovvie finché non ti rendi conto che in pratica non lo sono.
Mettiamola così: se il Refinement è l’attività di rendere “lavorabili” gli elementi backlog, lo scopo della “Definition of Done” è quello di rispondere a una semplice domanda: “cosa dobbiamo sapere per rendere lavorabile questo elemento?”.
Alcuni team usano un simpatico acronimo per definire quali caratteristiche ogni elemento dovrebbe possedere per essere considerato “pronto”: I.N.V.E.S.T.
- Independent
(Indipendente, ovvero può essere sviluppato senza dipendenze da altri elementi) - Negotiable
(Negoziabile, ovvero non costituisce un contratto specifico per i dettagli delle caratteristiche da implementare) - Valuable
(Di Valore per l’utente/cliente) - Estimable
(Stimabile con buona approssimazione) - Small
(Piccolo abbastanza da poter essere completato all’interno di uno Sprint) - Testable
(Testabile in linea di principio, anche se non esiste ancora un test)
Anche se trovo che questo sia un ottimo punto di partenza, penso che team diversi possano avere esigenze diverse a seconda del contesto e del dominio di lavoro, quindi, ognuno dovrebbe creare un elenco (o descrizione) più specifico di ciò che è necessario conoscere per ritenere un elemento “pronto”.
Molti dei team con cui ho lavorato nel settore IT utilizzano una checklist di questo tipo ancor prima di considerare un elemento stimabile:
- Se è un bug, come possiamo replicarlo?
- Se si tratta di una nuova funzionalità, qual è l’esperienza utente desiderata?
- Se richiede una nuova interfaccia utente, abbiamo i mockup o saranno progettati come parte dello Sprint?
- Se la nuova interfaccia utente sarà progettata all’interno dello Sprint, abbiamo tutti i contenuti/specifiche dell’interfaccia utente?
- Se si tratta di una modifica a un contenuto/interfaccia utente esistente, abbiamo le specifiche del contenuto/interfaccia utente precedenti e successive?
- Come possiamo testarlo? Abbiamo definito gli scenari di test?
Credo che una combinazione dell’uso dell’acronimo I.N.V.E.S.T. e una checklist simile a quella sopra possono davvero fare la differenza e consentire a qualsiasi team di velocizzare la propria produttività e moltiplicare il valore generato eliminando le perdite di tempo causate dalla necessità di rincorrere i requisiti e/o sottovalutare un elemento.
Fatemi sapere se usate la “Definition of Ready” nel vostro team e le vostre opinioni a riguardo.
