Definition of Ready (DoR), rendi le tue user story commestibili!

Mentre la Definition of Done stabilisce quali criteri rendono una user story “completata”, la Definition of Ready (abbreviato DoR) definisce quando una user story è pronta per essere inclusa in pianificazione.

Avere tutte le user story con priorità più alta “pronte” o “mature”, rende il lavoro di suddivisione in task più efficace e assicura che il team abbia una serie di prerequisiti in regola prima di iniziare l’attività di sviluppo.

Perché la Definition of Ready è importante

Lavorare su un requisito che non è “pronto” influisce negativamente sulla qualità del lavoro svolto. In alcuni casi può portare a un ritardo nella consegna e a incomprensioni all’interno del team.

Per evitare di incorrere in problemi durante la fase di esecuzione, è importante che una user story aderisca a una serie di criteri che la rendono matura per essere lavorata.

Esattamente come un frutto, una user story è molto meno digeribile se acerba e va quindi portata a giusta maturazione. Il team e il Product Owner concordano insieme questa lista di criteri, chiamata Definition of Ready, che rende una user story “edibile”. Come è solito nelle metodologie agili, la stesura della Definition of Ready è un altro momento di collaborazione e confronto tra i vari componenti del gruppo e va fatta tutti assieme.

È senz’altro compito del Product Owner maturare le user story in modo che soddisfino la Definition of Ready, prima di darle in pasto al team di sviluppo. Tuttavia questa attività non è quasi mai condotta in solitaria e tutto il team, con gli stakeholder ed eventuali business analyst (ma anche il cliente finale attraverso i suoi feedback), giocano un ruolo importante in questo processo.

Il Backlog Refinement meeting è un’ottima occasione per discutere le user story assieme al team e raggiungere un livello adeguato di comprensione.

In caso un requisito non rispetti la Definition of Ready, il team ha il diritto di chiedere al Product Owner di fornire ulteriori informazioni prima di includerlo nello Sprint Planning.

Com’è composta la Definition of Ready

La Definition of Ready deve essere composta da elementi piccoli e concreti, proprio come la Definition of Done. Più è piccola, meglio è.

Qui di seguito un esempio di Definition of Ready:

  • La user story rispetta il formato “As a user…”
  • La user story ha una stima in story point
  • C’è una breve descrizione dell’attività da svolgere
  • Gli acceptance criteria sono definiti e testabili
  • Il valore di business è specificato
  • Se presente, la documentazione tecnica deve essere allegata
  • Elementi grafici e mock-up, se presenti, devono essere allegati
  • I requisiti non funzionali (es. performance) sono specificati

Teoricamente può esistere anche più di una Definition of Ready, per esempio a livello di Epic o di Feature – ma entreremo più nel dettaglio in articoli successivi, dove imparerai come scalare Scrum. Per ora ti basta sapere che la Definition of Ready si applica a una user story affinché essa possa essere inclusa nello Sprint Planning.

La Definition of Ready può essere corretta e rivista al termine di ogni Sprint, se necessario. Il Retrospective meeting è il luogo in cui discutere miglioramenti da apportare alla nostra DoR.

Pericoli della Definition of Ready

Bisogna stare molto attenti a non cadere nella trappola “waterfall”. Se nella Definition of Ready si includono attività che devono essere completate prima di iniziare lo sviluppo della user story (esempio: analisi o design), si rompe l’agilità del team che prevede che tutte le fasi di sviluppo siano eseguite parallelamente all’interno dello Sprint.

Per tornare alla similitudine con il frutto di poco fa, una user story troppo matura marcisce. Il rischio è prendersi un bel mal di pancia!

Se il tuo team ha appena iniziato a lavorare con le metodologie agili o cade di continuo in tentazione, conviene mantenere la Definition of Ready estremamente snella. C’è chi suggerisce di non adottarla del tutto, ma dal mio punto di vista è necessario che le user story da includere in pianificazione rispettino certi standard di qualità, altrimenti c’è il pericolo di non mettere gli sviluppatori nella condizione giusta per avere successo nel proprio lavoro.

Note finali sulla Definition of Ready, ma non solo…

Trovo personalmente fondamentale rimarcare quanto detto nel paragrafo precedente. La Definition of Ready, ma anche il Refinement meeting (che ho citato più in alto) e lo Sprint Planning, non devono essere un’occasione per tentare di risolvere tutti i problemi prima di iniziare la fase di sviluppo. Questo scenario idilliaco, composto da percorsi senza ostacoli, semplicemente non esiste.

Bisogna accettare che il team affronti tutte le fasi di realizzazione (analisi, design, sviluppo, test…) parallelamente e all’interno dello Sprint, per ciascuna user story. Inclusa la risoluzione dei problemi.

A volte è troppo facile entrare in “solution mode” e cercare di analizzare e risolvere a priori ogni problema che potremmo ipoteticamente incontrare nel bel mezzo della nostra prossima iterazione. Se facciamo questo errore, corriamo il rischio di lavorare con un metodo “Frankenstein”, che non è né agile né waterfall, e rendere la nostra esperienza di lavoro “mostruosa”.

Lettura consigliata


libro story mapping
Jeff Patton

User Story Mapping: Discover the Whole Story, Build the Right Product

Formati: Kindle e Copertina flessibile, 324 pagine
Editore: O’Reilly Media
Lingua: Inglese