Guida Scrum | 23. Punti Storia e Stima in Scrum
Pubblicato: 2022-05-26Nell'articolo di oggi, trattiamo l'argomento Stima e Punti Storia in Scrum. La creazione di stime in Scrum aiuta a prevedere la complessità e il tempo necessari per completare le attività. Analizzando il passato, l'intero Scrum Team prevede collettivamente cosa riserva il futuro.
Pertanto, più lo Scrum Team è esperto, più accurate sono le loro stime. Il team collabora anche per stabilire il tempo stimato per completare le attività durante lo Sprint Planning, tenendo presente che non si tratta di un impegno finale ma di una previsione. La sua accuratezza dipende da numerose variabili che subiscono costantemente cambiamenti imprevedibili e circostanze impreviste. Fortunatamente, la metodologia Scrum include tecniche e strumenti per facilitare un certo grado di certezza, e oggi ne parleremo in dettaglio in modo che tu possa capirli e applicarli subito!
Punti Storia e Stima in Scrum – sommario:
- introduzione
- L'importanza dei Punti Storia in Scrum
- I punti storia sono unità relative. Ciò significa che:
- Tecniche di stima relativa
- Riepilogo
introduzione
Ad ogni Sprint Planning, il Product Owner presenta nuove User Story al team. Il Product Owner li seleziona dal Product Backlog per l'implementazione nel prossimo Sprint. Quindi i membri dello Scrum Team stimano congiuntamente il carico di lavoro necessario per completare questo nuovo lotto di compiti. Questo tipo di incarico è una stima, stima dei requisiti.
Sembrerebbe che il modo più semplice sia definire il tempo necessario per completare l'attività in ore o giorni. Tuttavia, la pratica e la ricerca condotte dagli anni '40 dimostrano il contrario. Gli esseri umani non sono in grado di stimare con precisione il tempo necessario per completare compiti anche molto ben definiti. Inoltre, il numero di ore necessarie per completare un'attività dipende da chi sta svolgendo l'attività e da cosa è stato (o non è stato) fatto prima. Questo è il motivo per cui Scrum usa tipicamente unità chiamate Story Points.
L'importanza dei Punti Storia in Scrum
Ciascun Team di Sviluppo mette in pratica il valore di uno Story Point attingendo dall'esperienza e dalla dimensione dei singoli compiti, cioè seguendo il principio dell'empirismo. Molto spesso, durante lo Sprint Planning, lo Scrum Master seleziona uno o più campioni di User Story completate, che fungono da punto di riferimento per determinare il valore delle User Story da sviluppare.
Ecco perché non puoi assegnare valori in Story Points senza il contesto. Ad esempio, se alla prima attività viene assegnato un valore di 10, le attività successive verranno valutate come maggiore o minore. In questo modo, all'interno di un progetto di Scrum Team, tutte le attività del Product Backlog sono correlate tra loro. Ciò significa che compiti simili eseguiti da un Team di sviluppo riceveranno un numero simile di punti.
I punti storia sono unità relative. Ciò significa che:
Il valore Story Point si riferisce solo ai compiti svolti da un particolare Scrum Team. I punti storia descrivono la velocità di completamento dei compiti di una squadra. In altre parole, una User Story stimata in 10 Story Point dalla Squadra A, può ottenere 50 dalla Squadra B. Questo perché, come accennato, il loro valore è relativamente calcolato rispetto ad altri compiti svolti da quella squadra, e la loro esperienza con compiti simili .
Il valore degli Story Point completati in uno Sprint non può essere la base per confrontare le prestazioni di due Scrum Team. 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 fare lo stesso lavoro in Sprint paralleli, che una squadra ha stimato a 10 e l'altra a 50 Story Point.
Non va inoltre dimenticato che la stima contiene molti elementi incogniti ed è effettuata sulla base di dati incompleti. Per questo motivo, le previsioni anche di uno Scrum Team molto esperto possono a volte essere molto diverse dal reale sforzo necessario per completare una User Story.
Tecniche di stima relativa
Quali sono le tecniche di stima più efficaci in Scrum? Non esiste un metodo valido per tutti che funzioni per ogni squadra.
Tra le tecniche di stima all'interno delle metodologie agili, le più comuni sono:
- Pianificazione del poker. Questo metodo relativo più popolare richiede un gioco di carte per calcolare la quantità di lavoro per completare un'attività. Sono regole dettagliate e processo che tratteremo in un articolo separato.
- Gioco di stima della squadra. Questo comporta l'assegnazione dell'esecuzione di User Story in un dato Sprint con valori numerici appropriati selezionati dalla sequenza di Fibonacci. Anche a questo abbiamo dedicato un articolo separato.
Scrum, d'altra parte, rifiuta il classico metodo della Stima Assoluta della tradizionale metodologia di project management. Il modo in cui stima le attività consiste nel definire in anticipo i mesi-persona, la durata e il costo dell'intero progetto. Si tratta di un processo lungo, di difficile attuazione, che richiede la partecipazione di esperti che tendono a stabilire la logica e il codice di condotta, ma non intraprendono alcuna azione che non eseguano necessariamente i compiti di cui stimano il valore. In altre parole, non è solo noioso ma anche altamente inefficiente.
Punti Storia e Stima - Riepilogo
La stima è un'abilità molto importante che caratterizza tutti gli Scrum Team maturi. La stima della quantità di tempo e fatica richiesta per completare le singole attività è diventata l'obiettivo principale di molte tecniche di stima relativa come Planning Poker o Team Estimation Game.
Le storie degli utenti con punti storia è un'altra tecnica di misurazione efficiente che abbiamo descritto, sperando di fornire ai nostri lettori alcuni strumenti utili. Tuttavia, è importante tenere presente che le loro figure si riferiscono solo ai compiti particolari svolti dallo Scrum Team. Pertanto, il numero di Story Point non può diventare la base per confrontare la velocità di diversi Team di Sviluppo.
Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Autore: Caroline Becker
In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.
Guida alla mischia:
- Glossario di termini, ruoli e nozioni di base
- Cos'è Scrum?
- Valori di mischia
- Come implementare Scrum nella tua azienda?
- Scrum Team: cos'è e come funziona?
- Chi è un Product Owner?
- Gli errori più comuni del Product Owner
- Chi è lo Scrum Master?
- Caratteristiche di un buon Scrum Master
- Gli errori più comuni di Scrum Master
- Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
- Collaborazione tra Product Owner e Scrum Master
- Team di sviluppo in Scrum
- Gli errori più comuni degli sviluppatori
- Artefatti di Scrum
- Scalare Scrum
- Sprint arretrato
- Cos'è il Product Backlog?
- Cosa sono le User Story?
- Creare la migliore User Story con INVEST
- Gli errori di User Story più comuni
- Criteri di accettazione della User Story
- Stima e Punti Storia in Scrum
- Pianificazione del poker
- Gioco di stima della squadra
- Incremento di definizione
- Eventi Scrum
- Cos'è lo Sprint in Scrum?
- Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
- Che cos'è un diagramma di burndown?
- Come creare e interpretare un diagramma di burndown?
- Vantaggi e svantaggi del diagramma di burndown
- Tavole Kanban in Scrum e Scrumban
- Velocity in Scrum - Velocità del Team di Sviluppo
- Scrum quotidiano
- Pianificazione dello sprint
- Recensione Sprint
- Che cos'è una retrospettiva sprint?
- Errori comuni durante una Retrospettiva Sprint
- Consolidamento del Product Backlog