La velocità non aumenta nel tempo, perché?

Ho tracciato il grafico della mia squadra in fiamme e la sua velocità per iterazione. A me sembra davvero male (la velocità fluttua molto). Cosa dovrei cercare per diagnosticare la causa principale di questo comportamento?

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

• Il team sta cercando di adattare le stime dei punti della storia in base alla velocità recente, invece di mantenere costanti i punti della storia e regolare il numero di storie che affrontano.
• Non stai distruggendo le storie abbastanza piccole.
• Troppe storie sono in granularità superiore. Ad esempio, hai molti 20 puntatori che sei riluttante a passare a 13 o 40.
• Hai un sacco di storie "da sbornia" che non sono ancora finite in uno sprint.

Stai abusando della velocità come indicatore di prestazione, come se un certo numero di punti storia accettati fosse uno sprint "buono" e qualcosa di meno che uno sprint "cattivo".

La velocità (che è un concetto terribilmente erroneo) dovrebbe essere utilizzata come uno strumento lungimirante per stimare quante funzioni a cui il team può impegnarsi nel prossimo sprint, vale a dire la velocità dovrebbe essere utilizzata per la pianificazione della capacità.

http://jimhighsmith.com/velocity-is-killing-agility/

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 ciò 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à della squadra per gli sprint futuri non può essere prevista molto bene. Sfortunatamente, non è una domanda a cui nessuno di noi può rispondere per te. Devi approfondire l'argomento tramite retrospettiva. Cosa sta succedendo davvero?

In ogni caso, la misura più critica non è presente nel grafico. Quanto ha fatto il team nel fornire il valore a cui si è impegnato? 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?

Ulteriore potenziale causa: durante gli sprint successivi, stai pagando il debito tecnico dagli sprint precedenti.

Ad esempio, hai una demo di gestione dopo lo sprint 3 e devi mostrare uno scenario felice. Per farlo, esegui la codifica senza gestione degli errori, senza supporto per la traduzione, senza test unitari. Questa è una decisione valida, devi solo essere consapevole delle conseguenze.

Quindi in seguito aggiungi tutte le belle cose come il framework di gestione delle eccitazioni, il supporto alla traduzione, il framework di unit test e così via. La tua codifica esistente dal 1 ° 3 sprint non lo utilizza ancora, quindi deve essere aggiornata. Questo sforzo rallenta la creazione di valore durante gli sprint successivi.

Per la tua domanda, è difficile dire perché abbia fluttuazioni perché potrebbe essere a causa della trama, delle persone nel team o della capacità del proprietario del prodotto. Quindi, nella mia esperienza, la velocità sarà fluttuata perché, ad esempio:

• Il tuo membro del team potrebbe non essere un membro del team dedicato. Per lavorare e capirsi, devono lavorare insieme abbastanza a lungo. Se la tua squadra scambia spesso le persone nella squadra dentro / fuori, questo rende dinamico nella squadra e influenza anche la velocità.
• Le carte Storia sono troppo grandi. Pertanto, il team non può entrare nei dettagli più che può nella pianificazione / stima. Durante lo sprint scopriranno che qualcosa è più difficile di quanto credano.
• Immagino tu stia facendo una mischia. In mischia, dobbiamo fare la pianificazione sprint parte 1 (Il proprietario del prodotto sceglie cosa fare) e la pianificazione sprint parte 2 (Il team decide quanto possono fare). Quindi, la situazione potrebbe essere, dopo che il proprietario del prodotto ha scelto le carte per lo sprint, il team non approfondisce abbastanza in dettaglio nella parte 2 della pianificazione dello sprint, quindi non riesce a trovare il problema nascosto di cui ha bisogno per far sapere al proprietario del prodotto. Se all'inizio hanno riscontrato i problemi, li romperanno O penseranno a come sbarazzarsi del rischio. Questo rende la stima sufficientemente corretta prima di iniziare a lavorare allo sprint.
• Se le carte trama non sono in dettaglio, la stima non sarà accurata. La stima all'inizio può essere approssimativa, ma prima di iniziare lo sprint o prima che le carte storia passino allo sprint, devono essere divise e chiarite abbastanza per 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 trama prima di iniziare a lavorare allo 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 carta per lo sprint e il team non lo capisce ancora, deve comunque capirli durante lo sprint e la risposta potrebbe rivelarsi che ha più di quanto hanno discusso e la stima è errata. Quindi, questo influenza chiaramente la velocità.
• eccetera...

Ad ogni modo, secondo me, non penso che la fluttuazione della velocità sia importante fintanto che sappiamo qual è la situazione di ogni sprint. La velocità è solo una cosa per dirti quanto può essere stabile la tua squadra. Se non è stabile, dobbiamo scoprire in dettaglio ogni sprint su "cosa è successo". Questo è solo un modo per chiarire / far accadere il problema in modo che possiamo risolverlo. Quindi, la velocità ci dice solo cosa stava succedendo in quello sprint a cui possiamo ripensare e migliorare per renderlo stabile. La velocità è una proiezione del progetto. E la fluttuazione della velocità non significa che il team non possa consegnare 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 abbastanza spesso una storia a metà strada viene portata al prossimo sprint.
• Le storie non sono state accuratamente stimate. Questo può essere a causa di un team inesperto o di nuovo storie troppo grandi.

Questo rumore non è necessariamente un problema da solo: una velocità rumorosa che fluttua attorno a una media costante consente comunque di pianificare accuratamente il rilascio.

Tuttavia, se si filtra il rumore (media mobile su 5 sprint consecutivi), la velocità diminuirà ancora dopo 20 sprint. Rende difficile eseguire la pianificazione del rilascio e vale la pena indagare:

• La "definizione di fatto" è troppo debole e il team sta accumulando lavoro residuo dagli sprint precedenti?
• L'organizzazione sta migliorando nel dirottare la mischia e imporre al team un lavoro senza arretrati?
• Le grandi storie (epiche) nella parte inferiore del registro posteriore sono state stimate più ottimistiche rispetto alle storie più dettagliate in cima?