Il momento giusto per il Planning Poker
Il Planning Poker è un metodo di stima basato sul consenso. Per questo motivo consiglio di utilizzarlo anche per gli item che richiedono consenso, ovvero più per i Product Backlog Item che per i Task di uno Sprint Backlog. In questo articolo approfondisco il Planning Poker e spiego quando è il momento giusto per utilizzarlo.
Motivi per stimare le User Story
La stima delle User Story in un Product Backlog ha due motivi:
1.) Il Product Backlog può essere prioritizzato. Immagina due Product Backlog Item che il Product Owner considera equivalenti. L'item con il costo più basso verrà affrontato per primo. Le valutazioni degli item dipendono quindi dai loro costi e possono essere utilizzate per la prioritizzazione.
2.) L'azienda può fare previsioni a lungo termine. L'entità del lavoro deve essere nota affinché il Product Owner possa indicare quando e quanto potrà essere consegnato.
Quando si dovrebbe giocare a Planning Poker?
Con l'aiuto dei punti sopra menzionati, si può capire quando un team dovrebbe effettuare delle stime. Da un lato, dovrebbe avvenire abbastanza presto da soddisfare entrambi i prerequisiti. Dall'altro, non dovrebbe avvenire prima del necessario.
Nella pratica, ci sono due situazioni in cui un team dovrebbe giocare a Planning Poker.
Un buon momento per il Planning Poker è, ad esempio, dopo uno Story Writing Workshop, in cui sono stati creati molti Product Backlog Item. Questi workshop dovrebbero essere condotti circa ogni trimestre.
In questo modo il Product Owner e il team possono definire un obiettivo più ampio (che non può essere raggiunto in un singolo Sprint) e creare le User Story necessarie.
Tipicamente, in uno Story Writing Workshop trimestrale vengono creati da 20 a 50 Product Backlog Item. Se si possono stimare circa 20 item all'ora, per la stima complessiva servono circa due ore a trimestre.
Inoltre, il Planning Poker può essere giocato anche una volta per Sprint. Alcuni team lo fanno durante il regolare meeting di Product Backlog Grooming. Questo va benissimo, purché tutti i membri del team siano coinvolti.
Se non tutti i membri del team sono coinvolti, il Planning Poker può essere giocato anche dopo un Daily Standup verso la fine di uno Sprint. Se un team effettua le stime troppo presto durante uno Sprint, potrebbe dover ripetere tutto per le Story aggiunte successivamente.
Tuttavia, la stima non dovrebbe avvenire troppo tardi. In quel caso, il Product Owner non potrebbe tenere conto di questi item nella definizione degli item per lo Sprint successivo.
Quando non si dovrebbe giocare a Planning Poker?
C'è un momento sfavorevole per il Planning Poker: all'inizio di uno Sprint Planning Meeting. A quel punto è troppo tardi perché il Product Owner possa orientare le proprie priorità in base alle nuove stime.
Ci sono forse Product Owner che riescono a riordinare le priorità in brevissimo tempo. Tuttavia, avere più tempo è sempre meglio.
Un altro problema è che un team quasi sempre dedica troppo tempo alle stime quando uno Sprint Planning inizia con il Planning Poker. Credo che ciò sia dovuto al fatto che i membri del team iniziano subito a pensare ai dettagli delle loro User Story.
Durante il Planning Poker, dovrebbero invece fornire una stima meno dettagliata delle loro User Story. È difficile dare una stima approssimativa in un meeting in cui si dovrebbero valutare i Task in modo molto più preciso.
Questo porta a discussioni inutili. E questo a sua volta fa sì che il team impieghi molto più tempo rispetto a quando le due attività vengono svolte separatamente.
Con queste linee guida, dovresti essere in grado di trovare il momento giusto per il Planning Poker.
Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.
