Story points: la gestione del lavoro nella metodologia Scrum

di Giorgia Frezza, il 08/02/21
story-points

La stima del tempo è alla base di un'adeguata pianificazione del progetto e di una consegna di successo. Pertanto, i manager e i loro team sono sotto pressione per sviluppare stime il più accurate possibile. Spendono molto tempo cercando di capire quanto tempo ci vorrebbe per completare i compiti senza ritardi e di solito arrivano a un valore fisso in ore, giorni o mesi.

Tuttavia, le ore non sono l'unico formato possibile per calcolare e presentare le stime di progetto. Un'alternativa sempre più popolare alla stima del tempo tradizionale, l’estimation degli story points (la stima degli story points), non si concentra affatto sulla durata probabile del progetto. Invece, aiuta a valutare l'entità dello sforzo che il compito o il progetto richiede.

Ma se è la prima volta che sentite parlare degli story points, potreste sentirvi un po’ disorientati. Non sono intuitivi come stilare un elenco dei compiti del team o calcolare la quantità di tempo necessaria per portare a termine un progetto.

Invece, se usate gli story points già da un po', potreste scoprire attraverso questo articolo che diversi team e organizzazioni li applicano in modo personalizzato.

Quindi, Appvizer oggi vi porta alla scoperta degli story points, spiegandovi cosa sono e perché sono così utili per i team scrum. Vi mostreremo anche alcuni dei diversi modi in cui i team li inseriscono all’interno della story mapping e nella pianificazione degli sprint.

Story points definizione

Gli story points sono una parte importante della story mapping, e la maggior parte dei team agili li usano per pianificare il loro lavoro per ogni sprint o iterazione.

Gli story points sono un'unità di misura utilizzata nell’agile project management (metodologia agile) e una parte importante del processo di story mapping.

Servono ad esprimere una stima del carico di lavoro complessivo che sarà richiesto per implementare completamente un product backlog item.

Un numero viene assegnato ad ogni story per estimare l’effort (l’energia, lo sforzo, il carico di lavoro) totale impiegato nel realizzare una caratteristica o funzionalità di un prodotto o servizio.

Cosa inserire in uno story point?

Poiché gli story point rappresentano l’effort per completare una user story, la stima di un team deve includere tutto ciò che può influenzare questo valore. Questo include:

  • The amount of work to do (la quantità di lavoro da fare)
  • The complexity of the work (la complessità del lavoro)
  • Any risk or uncertainty in doing the work (qualsiasi rischio o incertezza legata al lavoro)

Quando calcolare gli story points

Gli story points sono solitamente decisi durante la story mapping.

Dopo che i product owners hanno definito le user story, le hanno mappate nel dettaglio e le hanno messe in ordine di priorità, è il momento di quantificare gli story point. Il team lavora insieme per individuare gli story points per due motivi principali:

  • ogni membro del gruppo gioca un ruolo differente in diverse story
  • ogni componente dell’equipe conosce il lavoro coinvolto in UX (user experience), design, sviluppo, test e lancio, così come le diverse sottocategorie.

Bisogna assegnare gli story points ad ogni story prima di poter organizzare queste ultime verticalmente in sprint, dato che i membri del team avranno un tempo limitato per completare le story assegnate ad ogni sprint.

Per questo motivo, bisogna considerare attentamente quanto lavoro e quanta energia sono impiegate in ogni story, in modo da permettere al team la consegna del lavoro nei tempi stabiliti.

Come calcolare gli story points

Per conteggiare gli story points, bisogna prendere in considerazione l’effort totale coinvolto nella realizzazione di quella caratteristica o funzionalità che il cliente desidera aggiungere al suo product (prodotto o servizio) e che ne aumenterà il valore aggiunto.

Il tuo team dovrà porsi le domande seguenti:

  1. Quanto è complesso il lavoro?
  2. Quanto lavoro è necessario?
  3. Quali sono le capacità tecniche del team?
  4. Quali sono i rischi?
  5. Su quali parti non siamo sicuri?
  6. Di cosa abbiamo bisogno prima di iniziare o finire?
  7. Cosa potrebbe andare storto?

Il processo di stima degli story points

Questo è il punto in cui gli story points possono diventare un po' confusionari, dato che non hanno un valore universale stabilito. Dovrete, quindi, capire quanto valgono per voi e il vostro team.

Ecco come funziona:

  • Ad ogni story viene assegnato un certo numero di story points
  • I story points avranno un valore e un significato diverso in base al team o organizzazione
  • 1 story point per il tuo team potrebbe non essere uguale all’effort coinvolto in 1 story point per un altro team
  • L’effort coinvolto in 1 story point dovrebbe rimanere stabile per il tuo team ad ogni sprint e dovrebbe rimanere stabile da una story all’altra
  • 2 story points dovrebbero equivalere al doppio dello sforzo rispetto a 1 story point. 3 story points dovrebbero corrispondere al triplo dello sforzo rispetto a 1 story point... e così via
  • Il numero che assegnate non ha importanza - ciò che conta è il rapporto o ratio. Gli story points dovrebbero aiutarti a dimostrare l’effort relativo tra ogni story e ogni sprint.
story-points

©actiTime

Step 1: Come calcolare gli story points per la prima volta

Come abbiamo visto, gli story points sono relativi. Tuttavia, abbiamo pensato a darvi alcune stime di base per la prima volta che in cui dovrete contare gli story points. Questo vi darà un quadro di riferimento per tutte le story future.

Alcuni team usano la sequenza di Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ecc.) per le loro stime degli story points, piuttosto che una sequenza lineare crescente (1, 2, 3, 4, 5, 6, 7, ecc.) o una scelta numerica casuale.

💡Quali sono i vantaggi della sequenza di Fibonacci?

Per esempio, se state analizzando una story e cercate di stimare se uno story point è un 5, 8, o 13, è molto più veloce e più facile trovare una risposta che cercare di trovare il numero giusto tra, per esempio, 4-15. Sarà più facile raggiungere il consenso.

Inoltre gli intervalli tra i numeri in questa serie sono più ampi che nella scala lineare, il che rende più facile contrastare la differenza tra i valori assegnati ai differenti compiti.

Ma questo metodo presenta degli inconvenienti:

  • limita la scala di opzioni a disposizione. Per esempio, se una story è più impegnativa di 34, ma meno di 55, la stima sarà meno accurata.
  • non sarà possibile fare la media degli story points. Dovrete, invece, discutere con il team e decidere la migliore stima da un insieme limitato di opzioni.

Step 2: Identificare le user stories o altri elementi rilevanti

In questa fase, dovete semplicemente determinare ciò che il vostro progetto mira a realizzare: sviluppare un nuovo strumento innovativo, migliorare la funzionalità del vostro software, migliorare l'infrastruttura dei processi interni, ecc.

Step 3: Selezionare i punti di riferimento

I dati storici forniscono prove preziose per ottenere risultati di stima più accurati e credibili. Inoltre, è più conveniente stimare le attività quando si hanno dati con cui confrontarle. Per questo motivo, se avete già completato un progetto simile da qualche parte in passato, potete utilizzare le informazioni raccolte sulle sue prestazioni per sviluppare nuove stime.

Step 4: Identificare i rischi, la dimensione e la complessità dell'elemento o degli elementi di stima selezionati

Il volume di effort richiesto per il completamento del progetto dipende dalla quantità di compiti che comprende, la loro complessità, così come il numero di rischi e incertezze che il team può incontrare sulla strada. Perciò, in questo fase, bisogna:

  1. Identificare la dimensione della user story selezionata calcolando quanti compiti e sottocompiti devono essere eseguiti durante la sua realizzazione.
  2. Valutare la complessità dei compiti. (Scrivere 100 messaggi standard di due frasi non è la stessa cosa che creare 10 pezzi di descrizioni tecniche complete. Anche se quest'ultimo contiene meno sottocompiti del primo, molto probabilmente richiederà molto più sforzo per essere completato).
  3. Individuare quanti più rischi e incertezze possibili. Avete delle lacune nella conoscenza delle aspettative del cliente? Un ritardo nelle forniture, l'aumento del turnover dei dipendenti o il maltempo avranno un forte impatto sul vostro processo? Tutti i rischi e le incertezze rilevanti devono essere riflessi nella tua stima per ottenere risultati più accurati.

Step 5: Discutere e elaborare una valutazione

Una volta superato la fase precedente, è il momento di valutare ogni pezzo di lavoro in esame in base alla sua dimensione, complessità e rischi associati.

La stima delle story points è di solito effettuata attraverso la discussione con il team e, spesso, usando una tecnica di gamification conosciuta come Planning Poker o Scrum Poker.

Durante questo meeting:

  1. Tutti prendono familiarità con la user story selezionata e con gli obiettivi del progetto.
  2. I membri del team stimano anonimamente la dimensione, la complessità ed i rischi di quella story (cioè la loro probabilità e l'impatto), fornendo una stima per ognuno di questi aspetti separatamente.
  3. Poi, ogni partecipante presenta dei valori iniziali per ogni story points e, se corrispondono, il numero diventa la stima finale.
  4. Se non corrispondono, ogni membro del team dovrebbero spiegare le loro scelte e, dopo la discussione, la stima viene ripetuta fino a quando si raggiunge il consenso.
  5. In seguito, i valori finali dei punti per la dimensione, la complessità e i rischi della story sono sommati per ottenere la stima totale.

Step 6: Impostare le scadenze

Dopo che la stima finale dei punti story è stata concordata, è possibile prevedere quanto tempo il lavoro sulla story utente stimata richiederà alla fine determinando quanto velocemente ogni collaboratore è in grado di portare a termine un singolo punto story.

Per esempio, un compito riceve il valore totale di 100 punti story. Un membro esperto del team completerà 1 punto di story in 2 ore, e uno meno esperto - in 3 ore. Così, se le responsabilità per il compito sono equamente divise tra questi due dipendenti, la stima può essere convertita in ore come segue:

50 SP x 2 ore + 50 SP x 3 ore = 250 ore

Conoscendo questa cifra, si può facilmente determinare la scadenza del compito.

Usare i punti story per stimare la velocità del tuo team

Dopo un po' di tempo di lavoro insieme, la maggior parte dei team avrà un’idea del carico di lavoro associato a ogni story points.

Infatti, gli story point si rivelano utili per capire capire in quanto tempo il vostro team porta a termine uno sprint.

Per esempio, se il vostro team può completare 3 story points al giorno, in uno sprint di due settimane arriverà a finire 30 story points. Questa è la vostra velocity (velocità di crociera).

La velocity è utile per la story mapping e per lo sprint planning. Quando associate le vostre user stories a uno sprint, vi basterà controllare il totale di story points e assicurarvi che corrisponda alla vostra velocity. Così il vostro team non correrà il rischio di essere sovra o sotto-impegnato.

Story points VS Hours

Jeff Sutherland, il co autore della Scrum Guide nel suo articolo “why story points are better than hours” afferma:

Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down

Jeff Sutherland, why story points are better than hours

Come possiamo vedere, il grande punto di forza degli story points è l'accuratezza e l'efficacia, oltre alla loro flessibilità che permette di adattare gli sprint in funzione dei cambiamenti e delle modifiche sul product da parte del development team (team di sviluppo).

Per utilizzare correttamente questa tecnica, potrebbe essere necessario spendere un po' di tempo per imparare e fare pratica. Tuttavia, il tentativo vale sicuramente la pena.

Infatti, con l'aiuto della stima degli story points, avrete la possibilità di ottenere stime più accurate e meno rigide e di ripensare il vostro approccio di project management a beneficio dei membri del vostro team e del business nel suo complesso.