Guida Scrum | 23. Punti Storia e Stima nello Scrum

Nell’articolo di oggi, trattiamo il tema della Stima e dei Punti Storia in Scrum. Creare stime in Scrum aiuta a prevedere la complessità e il tempo necessario per completare i compiti. Analizzando il passato, l’intero Team Scrum prevede collettivamente cosa riserva il futuro.

Pertanto, più esperto è il Team Scrum, più accurate sono le loro stime. Il team collabora anche per stabilire il tempo stimato per completare i compiti durante la Pianificazione dello Sprint, tenendo presente che non è un impegno finale ma una previsione. La sua accuratezza dipende da numerose variabili che subiscono costantemente cambiamenti imprevedibili e circostanze inaspettate. Fortunatamente, la metodologia Scrum include tecniche e strumenti per facilitare un certo grado di certezza, e oggi ne discuteremo in dettaglio in modo che tu possa comprenderli e applicarli immediatamente!

Punti Storia e Stima in Scrum – indice dei contenuti:

1. Introduzione
2. L’importanza dei Punti Storia in Scrum
3. Tecniche di stima relative
4. Riepilogo

Introduzione

Ad ogni Pianificazione dello Sprint, il Product Owner presenta nuove User Stories al team. Il Product Owner le seleziona dal Product Backlog per l’implementazione nel prossimo Sprint. Poi i membri del Team Scrum stimano congiuntamente il carico di lavoro necessario per completare questo nuovo insieme di compiti. Questo tipo di assegnazione è una stima, stima dei requisiti.

Sembrerebbe che il modo più semplice sia definire il tempo necessario per completare il compito in ore o giorni. Tuttavia, la pratica e la ricerca condotta sin dagli anni ’40 dimostrano il contrario. Gli esseri umani non sono in grado di stimare con precisione il tempo necessario per completare anche compiti molto ben definiti. Inoltre, il numero di ore necessarie per completare un compito dipende da chi sta svolgendo il compito e da ciò che è stato – o non è stato – fatto prima. Ecco perché Scrum utilizza tipicamente unità chiamate Punti Storia.

L’importanza dei Punti Storia in Scrum

Ogni Team di Sviluppo mette in pratica il valore di un Punto Storia attingendo all’esperienza e alla dimensione dei singoli compiti, cioè seguendo il principio dell’empirismo. Più spesso, durante la Pianificazione dello Sprint, lo Scrum Master seleziona uno o più campioni di User Stories completate, che servono come punto di riferimento per determinare il valore delle User Stories da sviluppare.

È per questo che non puoi assegnare valori in Punti Storia senza il contesto. Ad esempio, se il primo compito ha un valore di 10, i compiti successivi saranno valutati rispetto ad esso come maggiori o minori. In questo modo, all’interno di un progetto del Team Scrum, tutti i compiti nel Product Backlog sono correlati tra loro. Ciò significa che compiti simili svolti da un Team di Sviluppo riceveranno un numero simile di punti.

I Punti Storia sono unità relative. Ciò significa che:

1. Il valore del Punto Storia si riferisce solo ai compiti svolti da un particolare Team Scrum. I Punti Storia descrivono la velocità di completamento dei compiti di un team. In altre parole, una User Story stimata a 10 Punti Storia dal Team A, può ricevere 50 dal Team B. Questo perché, come abbiamo accennato, il loro valore è calcolato relativamente ad altri compiti svolti da quel team e alla loro esperienza con compiti simili.
2. Il valore dei Punti Storia completati in uno Sprint non può essere la base per confrontare le prestazioni di due Team Scrum. Per evitare errori nella gestione dei progetti Scrum, è importante ricordare che la Velocità di un Team di Sviluppo espressa in Punti Storia realizzati in uno Sprint non può essere utilizzata per confrontare le prestazioni di due Team. Questo perché potrebbero svolgere lo stesso lavoro in Sprint paralleli, che un Team ha stimato a 10 e l’altro a 50 Punti Storia.

Non si deve nemmeno dimenticare che la stima contiene molti elementi sconosciuti ed è fatta sulla base di dati incompleti. Per questo motivo, le previsioni di anche un Team Scrum molto esperto possono talvolta essere molto diverse dallo sforzo reale necessario per completare una User Story.

Tecniche di stima relative

Quali sono le tecniche di stima più efficaci in Scrum? Non esiste un metodo universale che funzioni per ogni team.

Tra le tecniche di stima all’interno delle metodologie agili, le più comuni sono:

• Planning Poker. Questo metodo relativo più popolare utilizza un gioco di carte per calcolare la quantità di lavoro necessaria per completare un compito. Le sue regole dettagliate e il processo li tratteremo in un articolo separato.
• Team Estimation Game. Questo coinvolge l’assegnazione dell’esecuzione delle User Stories in un dato Sprint con valori numerici appropriati selezionati dalla sequenza di Fibonacci. Abbiamo dedicato anche un articolo separato a questo.

Scrum, d’altra parte, rifiuta il classico metodo di Stima Assoluta della metodologia tradizionale di gestione dei progetti. Il modo in cui stima i compiti è definendo in anticipo i mesi-uomo, la durata e il costo dell’intero progetto. Questo è un processo lungo, difficile da implementare e richiede la partecipazione di esperti che tendono a stabilire la razionalità e il codice di condotta, ma non intraprendono azioni per chi non svolgerà necessariamente i compiti il cui valore hanno stimato. In altre parole, non è solo noioso ma anche altamente inefficiente.

Punti Storia e Stima – Riepilogo

La stima è un’abilità molto importante che caratterizza tutti i Team Scrum maturi. Stimare la quantità di tempo e sforzo richiesti per completare singoli compiti è diventato il principale obiettivo di molte tecniche di stima relative come il Planning Poker o il Team Estimation Game.

Le User Stories con Punti Storia sono un’altra tecnica di misurazione efficiente che abbiamo descritto, sperando di fornire ai nostri lettori alcuni strumenti utili. Tuttavia, è importante tenere a mente che le loro cifre si riferiscono solo ai compiti particolari svolti dal Team Scrum. Pertanto, il numero di Punti Storia non può diventare la base per confrontare la velocità di diversi Team di Sviluppo.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.