Il principale vantaggio degli Story Point in Scrum
Se gli Story Point sono in fondo un'unità di misura del tempo (impegno), perché non usare direttamente ore o giorni? Perché servono gli Story Point?
Il motivo principale degli Story Point
Valutare i Product Backlog Item con gli Story Point ha diversi buoni motivi. C'è però un motivo principale che è del tutto sufficiente a giustificare gli Story Point. Ha a che fare con il re Enrico I, che regnò dal 1100 al 1135. Prima del suo regno esisteva l'unità di misura "yard", che corrispondeva alla distanza dal pollice teso al naso di una persona. Immagina che confusione doveva creare. Dopotutto, la distanza era diversa per ogni persona. Un giorno il re Enrico decise che uno yard sarebbe sempre stato pari alla distanza dal suo pollice teso al suo naso.
Questo era pratico per lui. Ma anche per tutti gli altri, perché ora esisteva un'unità di misura fissa. Per ogni singola persona significava che uno yard (la lunghezza del braccio del re) era forse un po' più lungo o più corto del proprio braccio. Così tutti avevano un'unità di misura uniforme.
Stima relativa con gli Story Point
Con gli Story Point funziona allo stesso modo. Come gli yard inglesi, gli Story Point permettono ai membri del team con competenze diverse di fornire insieme una stima relativa.
Si può anche fare un altro esempio: immagina di voler andare a correre con qualcuno. Tu corri a un ritmo piuttosto sostenuto, l'altro è più lento. Indichi un percorso e dici: "Prendiamo questo percorso, ci servono 30 minuti." Il tuo compagno di corsa, però, ogni volta che ha percorso quel tragitto al suo ritmo, ha impiegato 60 minuti e te lo dice. Allora discutete: "30". "60". "30". "60". Ma questo non vi porta da nessuna parte. Potreste trovare un compromesso e accordarvi su 45 minuti. Sarebbe però la cosa peggiore da fare, perché ora avreste una stima che non corrisponde a nessuno dei due. Invece di accordarvi su 45 minuti, discutete di nuovo: "30". "60". "30". "60".
A un certo punto dici al tuo compagno di corsa: "Ok, il percorso è di 5 km. Io lo percorro in 30 minuti." E lui risponde: "Giusto, il percorso è di 5 km. Ma io ci metto 60 minuti."
Il problema è che avete entrambi ragione. Tu riesci davvero a percorrere il tragitto in 30 minuti, il tuo compagno in 60 minuti. Dare una stima comune non funzionerà, dato che lavorate/correte a velocità diverse.
Se però si prende un'unità di misura più astratta – qui i chilometri – ci si può accordare. Vi accordate sul fatto che il percorso è di 5 chilometri. L'unica differenza è quanto tempo impiega ciascuno.
Conclusione – Consenso nonostante velocità di lavoro diverse
Gli Story Point servono allo stesso scopo. Grazie ad essi, persone con competenze e velocità di lavoro diverse possono raggiungere un consenso. Invece di un corridore lento e uno più veloce – come nell'esempio sopra – si possono immaginare due programmatori con produttività diverse:
Esattamente come i corridori, i programmatori possono concordare che una determinata User Story riceve 5 Story Point (invece di 5 km). Il più veloce dei due programmatori pensa forse che per lui sia solo un giorno di lavoro. Quello un po' più lento crede invece di aver bisogno di due giorni. Possono comunque accordarsi su 5 Story Point, poiché il numero di punti per la prima Story può essere scelto liberamente.
Da questa prima stima possono poi essere derivate tutte le successive per le Story seguenti. Se il più veloce dei due pensa che per la prossima Story avrà bisogno di due giorni (il doppio rispetto alla prima), assegna a questa Story 10 punti. Il programmatore più lento pensa forse di aver bisogno di quattro giorni (anche il doppio rispetto alla prima), e anche lui le assegna 10 punti.
E così gli Story Point – proprio come la lunghezza del braccio nella storia del re Enrico – aiutano persone diverse a raggiungere un consenso.
Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.
Creare una strategia di prodotto
Planning Poker
=> Il momento giusto per il Planning Poker
