La stima è uno degli argomenti più controversi nello sviluppo dei prodotti. Perché? Perché i team temono di essere ritenuti responsabili di cifre che sono, per loro natura, incerte. Alcuni aggiungono margini di sicurezza per “proteggersi”; altri sostengono che stimare un lavoro complesso sia inutile.
L'obiettivo della stima relativa è semplice: discussioni più costruttive sul problema. Il compito del Product Owner è quello di massimizzare il ROI valutando il valore aziendale in relazione all'entità e alla complessità del lavoro. La domanda è: “Che ritorno posso ottenere da questo investimento?” La valutazione relativa risponde a entrambe le parti di tale equazione: valore e investimento.
Pianificazione del poker È la tecnica di facilitazione che rende possibile tutto questo. Assicura che l’opinione di ogni membro del team venga presa in considerazione, mantenendo al contempo l’efficacia del processo. I team utilizzano schede cartacee o app per smartphone con una sequenza simile a quella di Fibonacci: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? – e ☕.
Il Planning Poker può essere utilizzato dai team e dai loro Product Owner per ottenere un comprensione dell'investimento, e può essere utilizzato dal Product Owner con le parti interessate per raggiungere un allineamento su valore aziendale atteso. Per entrambi i gruppi la procedura è la stessa.
Perché la stima relativa ha senso
I membri del team spesso esitano a formulare stime perché i loro numeri vengono considerati come impegni definitivi, a prescindere dalle ipotesi o dagli imprevisti che potrebbero presentarsi in seguito. Per “proteggersi”, aggiungono margini di sicurezza o moltiplicano le stime per un fattore (a volte π, per farle sembrare scientifiche). Ma l’accumulo di margini di sicurezza riduce la trasparenza e rende le stime inutili.
Ottenere stime precise richiede tempo, ma lo sforzo aggiuntivo raramente ripaga. Le stime non saranno mai precise al 100%, quindi dedicare meno tempo alla stima e più tempo alla realizzazione spesso porta a risultati migliori. La stima relativa tiene conto di questo: si tratta di dimensioni e complessità, non ore. Lo chiamiamo punti di storia.
Con la stima relativa non è necessario essere precisi, basta solo essere coerenti nel valutare quanto siano approssimative le proprie stime. Allo stesso tempo, la stima relativa aiuta i membri del team a condividere la propria comprensione del lavoro da svolgere e a concordare su quanto esso sia impegnativo.
Perché mai?
Il punto è questo: Peter, Paul e Mary non hanno tutti la stessa capacità di portare a termine determinati compiti. In alcuni compiti Pietro è più veloce di Paolo, perché ha più esperienza in quel campo. In altri compiti, Paolo supera Mary, mentre in altri ancora è Mary ad essere la più veloce. Allo stesso tempo, la motivazione e l’energia di Mary variano: alcuni giorni è piena di energia, altri è quasi a corto di carburante. Forse non ha dormito bene la notte scorsa. Nei giorni in cui è piena di energia, riesce a fare molto; in quelli in cui non lo è, il lavoro procede a fatica. Gli esseri umani non sono robot. Il nostro lavoro non è lineare: le interazioni e i risultati variano.
Per bilanciare questo aspetto, utilizziamo gli story point. Grazie agli story point, Peter, Paul e Mary possono concordare che un’attività valga 5, un’altra 13 e una terza 8 – anche se Peter è il più bravo nella prima, Mary nella seconda e Paul nella terza. È una scienza esatta? No. Ma col tempo le cose si bilanciano. È come un gioco di altalene: a volte si vince, a volte si perde. Stimare il lavoro complesso non è mai stata – e non sarà mai – una scienza esatta.
Per separare gli story point dal tempo, il team deve disporre di un riferimento sulla base del lavoro già svolto – di solito li chiamiamo “user story”. Il team costruisce questo riferimento confrontando tra loro i diversi elementi di lavoro. Qual è un 3, qual è un 5, qual è un 8? Il team dovrebbe mantenere e perfezionare il proprio riferimento nel tempo, assicurandosi che non si discosti troppo.
Una metafora per comprendere gli story point
Consideriamo un compito semplice: spostare un mucchio di sabbia. Le due persone che stanno per svolgere questo compito possono concordare approssimativamente sul suo volume (dimensioni) e possono anche concordare sulla complessità dell’operazione. A dire il vero, spostare la sabbia non è poi così complesso, a meno che la sabbia non sia inquinata, il che renderebbe il lavoro più complesso perché richiederebbe una gestione e attrezzature speciali.
Il lavoro di spostamento della sabbia presenta una certa combinazione di entità e complessità: potremmo dire che questo lavoro sia un 8. Se si trattasse di sabbia inquinata, potrebbe essere un 13 o un 20. Tuttavia, questo non dice nulla sul tempo che ci vorrà. Ciò dipende da come viene gestito il lavoro in termini di personale. Se una persona sposta la sabbia, ci vorrà un certo tempo; se lo fanno due persone, il tempo necessario sarà diverso (si spera inferiore). Forse le due persone non hanno la stessa abilità nel spostare la sabbia. Forse una ha mal di schiena: in tal caso ci vorrà più tempo se quella persona lavora da sola. Se ci pensa l’altra persona, il lavoro procederà più velocemente. Forse gli attrezzi variano: un giorno usano secchi, un altro giorno carriole e un terzo giorno un escavatore. Il tempo varierà, ma la combinazione di entità e complessità rimane la stessa. È sempre un 13, indipendentemente da quante persone svolgano il lavoro o da quali attrezzi utilizzino.
Non è una scienza esatta, ma col tempo i risultati si stabilizzano – soprattutto se si mantengono costanti il riferimento e la squadra.
Come giocare
All’inizio del Planning Poker, a ciascun membro del team viene consegnato un mazzo di carte. Per ogni user story o tema da stimare:
- Un moderatore – in genere il Product Owner, il Scrum Master o un analista – legge la descrizione. Il il moderatore non vota.
- Ogni membro del team sceglie in segreto il valore di una carta in base alla loro comprensione della storia, confrontandola con il riferimento fornito dal team.
- Quando tutti hanno fatto la propria scelta, tutte le carte vengono scoperte contemporaneamente.
- I membri del team con il valori massimi e minimi esporre il proprio ragionamento.
- Il Product Owner, ovvero il referente, risponde a tutte le domande poste dal team.
- Ogni membro del team nuove stime selezionando in privato una nuova carta.
- Tutte le schede vengono visualizzate nuovamente in modo che tutti possano vedere le stime aggiornate.
- I membri del team con i valori più alti e più bassi discutere il loro ragionamento ancora una volta.
- Al termine della discussione, ogni membro del team ricalcola il tempo finale.
- Se ce n'è solo una differenza di un solo passo tra le carte rimanenti, la viene scelto il valore più alto.
- Se c'è ancora nessun consenso dopo il terzo turno, il viene scelto il valore più alto.
L'uso del Planning Poker per il valore aziendale
Lo stesso vale per il valore aziendale. In questo caso, il Product Owner e le parti interessate coinvolte effettuano la relativa stima. Proprio come il team dispone di un punto di riferimento per gli story point, anche il Product Owner e le parti interessate dovrebbero avere un punto di riferimento per il valore aziendale – preferibilmente funzionalità che abbiano già dimostrato il proprio valore sul mercato.
Durante la fase di valutazione, il loro dialogo sul valore aziendale dovrebbe andare oltre la semplice questione economica. Potrebbero discutere di:
- Questa funzionalità consentirà di... nuovi mercati per noi?
- Può esserci d'aiuto? upsell ai clienti già esistenti?
- È necessario per mantenere la nostra posizione sul mercato?
- Ci saranno miglioramenti? efficienza?
- È previsto da normativa?
- Questo rafforzerà il nostro marchio?
Nessuno di questi aspetti è intrinsecamente migliore degli altri, ma ciò che conta sono il confronto e la sintonia.
L'uso della stima relativa nelle previsioni
Lo scopo della stima è quello di creare piani prevedibili. Ciò è quasi impossibile quando si svolge un lavoro complesso, ma questo non dovrebbe impedirci almeno di provarci. Per quanto ci riteniamo allineati al modello Agile, c’è comunque bisogno di punti di sincronizzazione come milestone o gate. Altri reparti – quali produzione, vendite o marketing – hanno bisogno di sapere quando finiremo di sviluppare una funzionalità o un prodotto. Anche se i piani sono destinati a cambiare, dovremmo comunque fornire la nostra migliore stima su cosa succederà e quando avremo finito.
L'utilizzo della stima relativa basata sugli story point, oltre alla misurazione del numero di story point che il team consegna in ogni sprint (la sua velocità), consente al Product Owner di effettuare piani piuttosto prevedibili. Grazie alla disponibilità del team a fornire stime sulle attività del Product Backlog – anche se descritte solo brevemente – per il Product Owner diventa semplice stabilire quali attività possano essere inserite in quali sprint. Ciò garantisce trasparenza sui piani e sui progressi, aiutando il Product Owner a discutere le priorità con le parti interessate e a prendere le decisioni migliori possibili.
La sfida principale nell'utilizzo della velocità è che essa varia nel tempo. Diversi fattori influiscono su questo aspetto:
- Disponibilità dei membri del team a lavorare in gruppo
- Interruzioni nell'attività lavorativa quotidiana
- Variazioni nel grado di corrispondenza tra le competenze del team e i compiti attuali
- L'impegno e la dedizione dei membri del team nel perseguire l'obiettivo Sprint Goal
Un buon modo per affrontare questa incertezza è quello di utilizzare il 90% Intervallo di confidenza della velocità. Sebbene alla base di questo concetto vi siano formule statistiche, in pratica si utilizza il la seconda velocità più alta e la seconda velocità più bassa sulla base degli ultimi otto sprint, per definire l'intervallo su cui basare la velocità futura.
Alcuni team prevedono un margine di sicurezza nello sprint per il lavoro non pianificato. Tuttavia, ricorrere alla stima relativa con gli story point e basare l’impegno e le previsioni sulla velocità misurata significa questo buffer è già stato considerato. Se un team pianifica il lavoro in base alla propria velocità attuale, il margine necessario è già intrinsecamente incluso.
Non è una scienza esatta, ma col tempo i risultati si stabilizzano – soprattutto se si mantengono costanti il riferimento e la squadra.
Pensieri finali
L'uso della stima relativa offre un modo semplice per districarsi nella complessità dello sviluppo dei prodotti nel mondo moderno. Tuttavia, la capacità di farlo non nasce dal nulla: affinché funzioni, è necessario che sia soddisfatta una lunga serie di condizioni. Tra queste figurano:
- Una chiara comprensione e un senso di responsabilità nei confronti del team finalità e obiettivi
- Squadra stabilità e le interrelazioni
- L'accordo della squadra su ruoli e responsabilità
- I modelli Product Owner mandato e disciplina nell'affinamento del backlog
- La capacità del Scrum Master di proteggere la squadra a causa di lavoro non programmato
Come potete vedere, l’uso della stima relativa prevede una struttura e un processo ben definiti, ma alla fine tutto dipende dalla cultura aziendale. La stima relativa funziona solo se si accetta l’incertezza insita in un lavoro complesso e si dà al team la libertà di decidere autonomamente come portare a termine il lavoro. Se si cambia continuamente la composizione del team, questo approccio non funzionerà mai.
