La velocità non si placa nel tempo, perché?

È perfettamente normale avere una fluttuazione nei primi dieci o più sprint, mentre la squadra sta trovando il suo ritmo. Dopodiché, è perfettamente normale che la velocità fluttui intorno alla media. Prova a tracciare una media corrente degli ultimi cinque sprint o giù di lì e dovresti vederlo livellato. In caso contrario, alcuni dei seguenti potrebbero essere i colpevoli:

• Il team sta cercando di aggiustare le stime dei punti storia in base alla loro velocità recente, invece di mantenere costanti i punti della storia e di regolare il numero di storie che prendono.
• Non stai rompendo le storie abbastanza in basso.
• Troppe delle tue storie sono in granularità più elevate. Ad esempio, hai un sacco di 20 puntatori che sei riluttante a cambiare in 13 o 40.
• Ci sono un sacco di storie di "sbornia" che non sono state completate in uno sprint.

Ti stai abusando di velocità come indicatore di prestazioni, come se un certo numero di punti storia accettati fosse uno "buono" sprint e qualsiasi cosa di meno che sia uno sprint "cattivo".

La velocità (che è un concetto terribilmente errato) dovrebbe essere usata come uno strumento lungimirante per stimare quante funzioni il team può impegnare nel prossimo sprint, cioè la velocità dovrebbe essere utilizzata per la pianificazione della capacità.

link

Ecco una citazione saliente dell'articolo: "Il problema è il peso dato alla velocità e trasformandolo in una misura di produttività."

Potrebbe esserci un problema in quello che sembra essere una varianza significativa nella tua velocità. Ciò non significa che la squadra stia facendo qualcosa di sbagliato, ma l'effetto è che la capacità del team per gli sprint futuri non può essere prevista molto bene. Sfortunatamente, non è una domanda che nessuno di noi può rispondere per te. Hai bisogno di scavare nel soggetto via retrospettiva. Cosa sta succedendo davvero?

In ogni caso, la misura più critica manca dal tuo grafico. Quanto bene ha fatto il team nel fornire il valore a cui si sono impegnati? La velocità fluttua perché supera il loro impegno in alcuni sprint ma non in altri, fluttua perché non stanno finendo le storie, o fluttua perché anche gli impegni fluttuano?

Altre potenziali cause: durante gli sprint successivi, stai pagando il debito tecnico dagli sprint precedenti.

es. hai una demo di gestione dopo lo sprint 3 e devi mostrare lo scenario di un giorno felice. Per farlo, si esegue la codifica senza la gestione degli errori, senza supporto per la traduzione, senza test delle unità. Questa è una decisione valida, devi solo essere consapevole delle conseguenze.

Quindi in un secondo momento aggiungerai tutte le cose carine come il framework di gestione delle excation, il supporto per la traduzione, il framework dei test unitari e così via. La tua codifica esistente dai primi 3 sprint non l'ha ancora utilizzata, quindi deve essere aggiornata. Questo sforzo rallenta la creazione del valore durante gli sprint successivi.

Per la tua domanda, è difficile dire perché ha delle fluttuazioni perché potrebbe essere dovuto a story card, persone nel team o al proprietario del prodotto. Quindi, secondo la mia esperienza, la velocità sarà fluttuante perché, ad esempio:

• I membri del tuo team potrebbero non essere membri del team dedicati. Lavorare e capirsi, hanno bisogno di lavorare insieme abbastanza a lungo. Se la tua squadra scambia spesso persone nel team in / out, questo rende dinamico il team e influenza anche la velocità.
• Le carte storia sono troppo grandi. Quindi, la squadra non può andare nel dettaglio più che può nella pianificazione / stima. Durante lo sprint troveranno che qualcosa è più difficile di quanto pensano.
• Immagino che tu stia facendo mischia. In mischia, dobbiamo fare la parte di pianificazione sprint 1 (il proprietario del prodotto sceglie cosa fare) e la parte di pianificazione sprint 2 (la squadra decide quanto possono fare). Quindi, la situazione potrebbe essere, dopo che il proprietario del prodotto ha scelto le carte per lo sprint, la squadra non entra nel dettaglio abbastanza in profondità nella parte 2 di sprint planning in modo che non possano trovare il problema nascosto di cui hanno bisogno per far sapere al proprietario del prodotto. Se hanno trovato i problemi all'inizio, li romperanno o penseranno a come sbarazzarsi del rischio. Questo rende la stima sufficientemente corretta prima di iniziare a lavorare sullo sprint.
• Se le story card non sono dettagliate, la stima non sarà accurata. All'inizio la stima può essere approssimativa, ma prima di iniziare lo sprint o prima che le story card vadano alla sprint, devono essere divise e chiarite abbastanza da ottenere una stima quasi corretta. Questo aiuta la velocità della squadra ad essere più stabile.
• Il proprietario del prodotto potrebbe non essere in grado di chiarire abbastanza chiaramente le carte storia prima di iniziare a lavorare sullo sprint. Questa è anche una cosa molto importante perché questo è l'obiettivo per il team di lavorare in queste 2 settimane. Se il proprietario del prodotto sceglie semplicemente la scheda per lo sprint e il team non lo capisce ancora, devono comunque capirli durante lo sprint e la risposta potrebbe rivelarsi che ha più di quanto discusso e la stima è sbagliata. Quindi, questo influenza chiaramente la velocità.
• ecc ...

Ad ogni modo, secondo me, non penso che la fluttuazione della velocità sia importante finché sappiamo quale sia la situazione di ogni sprint. La velocità è solo una cosa per dirti quanto può essere stabile il tuo team. Se non è stabile, dobbiamo scoprire nel dettaglio di ogni sprint su "cosa è successo". Questo è solo un modo per chiarire / far si che il problema si verifichi, quindi siamo in grado di risolverlo. Quindi, la velocità ci dice solo che cosa stava succedendo in quello sprint per poterlo ripensare e migliorare per renderlo stabile. Velocity è una proiezione del progetto. E la fluttuazione della velocità non significa che la squadra non può fornire il prodotto, ti aiuta solo a pensare alla proiezione in futuro e quali sono i problemi da risolvere per rendere tutto più fluido.

La tua velocità ha rumore (fluttuazioni). Possibili ragioni:

• Le storie sono troppo grandi e molto spesso una storia a metà strada viene portata al prossimo sprint.
• Le storie non sono state accuratamente stimate. Questo può essere dovuto a una squadra inesperta o ancora a storie troppo grandi.

Questo rumore non è necessariamente un problema di per sé: una velocità rumorosa che oscilla attorno a una media costante consente comunque di eseguire una pianificazione accurata del rilascio.

Tuttavia, se si elimina il rumore (media mobile su 5 sprint consecutivi), allora la velocità continua a scendere dopo 20 sprint. Rende difficile programmare la release e vale la pena investigare:

• La "definizione di fatto" è troppo debole e la squadra sta accumulando il lavoro rimasto da precedenti sprint?
• L'organizzazione sta migliorando la deviazione della mischia e impone un lavoro non arretrato al team?
• Le grandi storie (epiche) nella parte inferiore del backlog sono state valutate più ottimistiche rispetto alle storie più dettagliate in cima?