Nel post precedente abbiamo inquadrato la tematica legata all’Agile Planning, descrivendo l’Agile Planning Onion e i vari momenti e livelli a cui le varie attività vengono svolte.
Come visto, a livello di Product Planning vengono definite le funzionalità dello specifico prodotto, affidandone la governance ad un Product Owner (PO) e creando il ben noto Product Backlog.
Product Backlog
Questo artefatto è sotto l’esplicita ed univoca governance del PO, ed è, come tutti gli artefatti Agili, soggetto a continui aggiustamenti ed allineamenti. Proprio in tale ottica, lo stesso co-autore di Scrum, Ken Schwaber, ha definito fondamentale l’attività di Grooming, nonostante essa non sia direttamente contemplata nella metodologia, suggerendo di dedicarvi non più del 5% del tempo di un’iterazione (4h per 2settimane) e assimilandola, nella forma e nei modi, al Daily Meeting.
Il Grooming è un’attività di pre-planning in quanto consente di preparare al meglio il Product Backlog in vista dell’inizio del prossimo Sprint, basandosi su quanto emerso durante l’iterazione corrente.
A questo punto una domanda dovrebbe sorgere spontanea: ma perché non unirlo allo Sprint Planning? La domanda è legittima, ma lo Sprint Planning ha una caratterizzazione molto forte che prevede l’individuazione degli obiettivi da raggiungere (Goal), la scelta di cosa realizzare e la definizione di massima di come realizzarlo. Quindi non vi è spazio per l’attività di Grooming che potrebbe essere anche di durata equivalente allo Sprint Planning stesso. In generale, lo Scrum Team si aspetta che, all’atto di avvio dello Sprint Planning si abbia:
- Un Product Backlog priorizzato in funzione delle esigenze dettate dal Product Owner;
- Una serie di User Story pronte ad essere inserite nel prossimo Sprint Backlog;
- La definizione dei Criteri di Accettazione per le User Story stesse.
E’ evidente, quindi, che bisogna trovare un momento diverso per effettuare il grooming (o pre-planning che si voglia). In base all’esperienza diretta, non si tratta di un solo momento ma è opportuno dividere il grooming in due sessioni pre e post Sprint Review, andando a focalizzare l’attività, separatamente, su due aspetti specifici:
- [Session 1] Rivedere il Product Backlog in funzione di quanto emerso durante lo Sprint;
- [Session 2] Rivedere il Product Backlog in funzione di quanto emerso durante la retrospettiva.
Grooming and Sprint Review
Nella Session 1 (2h/2sett) è molto probabile che si parlerà prevalentemente dei problemi di natura tecnica annessi alle User Story sviluppate o a quelle non completate, andando così ad effettuare un audit del Product Backlog Risk related. Dualmente, nella Session 2 (2h/2sett) il focus sarà sulla review funzionale di quanto realizzato, basato essenzialmente sui feedback dei (key) stakeholders e quindi Feedback Related.
Entrambe le sessioni sono appannaggio dello Scrum Team al completo (quindi: Product Owner, Scrum Master e Development Team) allo scopo di condividere il know-how relativo al prodotto, puntando ad ottenere una visione condivisa delle singole User Story, effettuando la stima del relativo effort, evidenziandone gli elementi critici e le possibili soluzioni agli impedimenti riscontrati. Non da ultimo, il grooming è il momento in cui condividere quelli che sono gli Acceptance Criteria e discutere del loro peso all’interno del processo di sviluppo, valutando quali sono strettamente necessari e quali possono essere eventualmente deferiti.
