Il nostro team è abbastanza bravo a pianificare / puntare, ma una volta in una luna blu, avremo una storia severamente sottotitolata. Sto parlando di qualcosa pensavamo che ci sarebbero voluti un paio di giorni e ci siamo resi conto che avrebbe preso l'intero sprint. Qual è l'approccio consigliato per risolvere questo problema quando realizziamo il nostro errore in modo che non renda la nostra velocità inutilizzabile per la prossima pianificazione dello sprint?
Non appena identificate una storia che è troppo grande da assorbire nell'iterazione corrente, il vostro team deve fare quanto segue al più presto:
Comunicare la tua preoccupazione all'intero team. Dato che hai taggato questa scrum devi parlare con Scrum Master e Product Owner in particolare, ma tutti devono essere consapevoli.
Identifica ciò che ha richiesto più tempo. Le probabilità sono che ci fosse qualcosa mancato durante la stima. O un requisito mancato o qualcosa di veramente più duro di quello che sembrava (ad esempio, alcune funzionalità non possono essere implementate nel modo in cui hai assunto in precedenza a causa di una limitazione della struttura).
Crea una nuova stima in base alle nuove informazioni.
Programmalo.
Se è troppo grande per un singolo sprint o ha senso dividerlo in più storie, suddividilo in più storie e spostale nel backlog . Se possibile, sposta una delle nuove (più piccole) storie nello sprint corrente nello spazio ora vuoto.
Altrimenti se la sua nuova dimensione è abbastanza piccola per l'iterazione corrente, lasciatela a posto (non è probabile nel tuo caso ma è un buon passo avanti per il caso generale).
Altrimenti spostalo sul backlog.
Lasciare che la storia scivoli può sembrare brutta, ma sai cosa è peggio? Perpetua crunch-time e tutto ciò che viene fornito con procrastinazione e mancanza di pianificazione.
Le tue azioni dovrebbero essere determinate se la diminuzione della velocità a causa di una storia sottovalutata è un'escursione di una sola volta o rara, o una tendenza che suggerisce che il tuo processo di sviluppo necessita di refactoring.
Servono metriche migliori per rilevare la differenza. IMO, calcolando la velocità media rispetto agli ultimi due sprint non è sufficiente. Dovresti raccogliere tutti gli sprint precedenti per rilevare le tendenze a lungo termine.
All'inizio di un progetto, le stime dello sforzo del team saranno probabilmente in errore rispetto allo sforzo effettivo. Ci si può aspettare che la velocità dallo sprint allo sprint mostri ampie fluttuazioni. Man mano che il team acquisisce maggiore familiarità con le attività del progetto e con una stima migliore, dovrebbe esserci meno fluttuazione e la velocità dovrebbe convergere in un valore sostenibile coerente con un intervallo di variazione minore. In termini statistici, la deviazione standard della velocità dovrebbe iniziare una frazione abbastanza grande della velocità, ma convergere in una frazione piuttosto piccola della velocità.
Se la tua velocità mostra consistenti fluttuazioni dallo sprint allo sprint in modo coerente, ciò suggerisce che il tuo processo di stima necessita di miglioramenti. Ci sono molte azioni che potresti intraprendere, a seconda delle specifiche del tuo programma. Si tratta di addestrare gli sviluppatori a fare meglio la stima, è una questione di migliore comprensione del dominio del problema, ci sono problemi politici che rendono il processo di stima inaffidabile? Tutti questi e altri sono le possibilità.
Se questo non è il caso e la velocità è convergente, ma la storia sottovalutata è un'escursione di una sola volta: ciò non rende la velocità media mobile complessiva inutilizzabile per il prossimo sprint.
Ciò che fa è rendere la stima del contributo relativo della tua storia anomala alla velocità troppo piccola.
È necessario ricostituire il contributo della storia anomala alla velocità del prossimo sprint, aumentandolo di un fattore che tiene conto della stima errata. Quindi è necessario apportare modifiche allo sprint per mantenere la velocità al valore sostenibile.
Questo può significare spingere altre storie al backlog se la storia sottovalutata ha una priorità più alta o dividere la storia in storie più piccole da affrontare su più sprint se altre storie non possono essere spinte al backlog.
What is the recommended approach to fix this when we realize our error
Le stime sono stime . Non lo vedrei come qualcosa da riparare, quando succederà. Lo considererei un'opportunità per diagnosticare le ragioni e migliorare le stime future. Dal momento che lo scopo di Scrum è l'incremento di alta qualità del prodotto consegnabile, vuoi fermarti e valutare quale è l'incremento di migliore qualità che sei in grado di fornire, dato che ora ti accorgi che inizialmente "hai morso più di quanto potresti masticare" .
...so that it doesn't make our velocity unusable for the next sprint planning?
Non è necessario essere schiavi del tuo metodo di calcolo della velocità. Ad esempio, potresti scegliere di considerare i dati dello Sprint corrente come "anomali" e non utilizzarli nel calcolo (che presumo sia una sorta di media mobile degli scorsi precedenti). Fai attenzione, tuttavia, che se ti trovi a voler ignorare l'effetto dello sprint corrente sulla velocità spesso ... potresti sovrastimare la tua velocità.