Come gestire il 50% degli sprint peggiori rispetto alla media?

Se capisco correttamente Scrum, è così che determino il lavoro che il mio team può svolgere nel prossimo sprint:

1. Ho calcolato la media del numero di punti completati negli ultimi sprint.

2. Questa quantità è la nostra velocità media. Al prossimo sprint, affrontiamo molti punti della storia.

Questa è una media , quindi se la storia si ripete, questo sprint ha il 50% di probabilità che stiamo prendendo troppo pochi punti della storia e il 50% che stiamo prendendo troppi punti della storia.

Nel caso del 50% abbiamo preso troppi punti della storia che potremmo:

• Impossibile completare lo sprint. Ciò significa che non riusciremo a rispettare il nostro impegno sprint per la metà del tempo.

• Lavora in più per recuperare il ritardo. Il problema è che questo cricchetto solo in un modo. Realizzeremo lo sprint e il numero di punti trama completati lo rifletterà. Dal momento che finiamo sempre, nel tempo, la nostra media tenderà verso l'alto fino al punto in cui realizziamo sempre un gran numero di punti della storia e restiamo in ritardo.

La mia comprensione della velocità media e degli impegni di sprint è corretta?

In tal caso, cosa dovremmo fare per il 50% degli sprint dove siamo in ritardo rispetto alla media?

In caso contrario, cosa ho sbagliato?

La mia comprensione della velocità media e degli impegni di sprint è corretta?

Sì, ne hai l'essenza.

In caso contrario, cosa ho sbagliato?

La cosa che trascurato è che i punti di storia sono le cose che si ottiene fatto . È quasi impossibile per tutti lavorare su storie fino alla fine dello sprint. Se stai facendo le cose nel modo giusto, la maggior parte dei tuoi sviluppatori rimarranno "inattivi" per alcuni giorni mentre le storie vengono testate (e i tuoi tester al centro dello sprint mentre lo sviluppo è in pieno svolgimento).

Metto inattivo le virgolette perché i tuoi sviluppatori non sono seduti a guardare video di gatti, stanno riparando bug, lucidando alcuni test di codice / unità, aggiungendo un po 'di documentazione sui processi, pensando al design per storie nel backlog o in uno dei altre dozzine di cose utili di cui un team di sviluppo può beneficiare ma che non si adattano bene a una storia.

Quindi, mentre indovinerai il 50% delle volte e indovinerai il 50% delle volte, ciò non significa che fallirai lo sprint o dovrai fare gli straordinari . Significa che non avrai abbastanza tempo per fare questo lavoro vario (a meno che non ti manchi davvero le tue stime). Ma questo non è un grosso problema, dal momento che il lavoro vario non è sensibile al tempo e le cose andranno anche a lungo termine.

La mia comprensione della velocità media e degli impegni di sprint è corretta?

Sfortunatamente, sei stato male informato su alcune cose riguardanti Sprint Planning in Scrum. Innanzitutto, il team di sviluppo (DT) lo è

... strutturato e autorizzato dall'organizzazione per organizzare e gestire il proprio lavoro. - Scrum Guide

La parola per questo è auto-organizzata. Ciò include il lavoro di previsione del lavoro che verrà svolto in un determinato Sprint. Al DT non viene detto cosa funzionerà ad ogni sprint, è piuttosto autorizzato a scegliere il proprio lavoro. Il DT potrebbe aver bisogno di informazioni come la velocità storica, un Product Backlog ben rifinito e la capacità DT del prossimo Sprint per creare una previsione. In definitiva, è la determinazione del DT di ciò che può e non può essere realizzato in uno Sprint che dovrebbe prevalere nelle loro previsioni; non dovrebbero essere informati di quanto lavoro faranno.

Si noti inoltre, previsioni e non impegno. La parola c è stata rimossa dalla Scrum Guide perché veniva utilizzata per abusare del team di sviluppo. La previsione è il termine preferito.

Per quanto riguarda la probabilità di perdere la previsione Sprint nella fascia bassa o alta, non ritengo che sia importante. Ad un certo punto, più analisi non producono una migliore precisione e penso che ora siamo oltre quel punto.

Inoltre, uno Sprint può essere solo "Annullato;" non può mai fallire. Uno Sprint viene annullato solo quando l'obiettivo dello Sprint diventa completamente obsoleto e irrilevante. Questo è molto raro. Se una previsione non è corretta, mantieni la calma e Scrum. Hai una retrospettiva. Al prossimo Sprint, le tue previsioni saranno migliori :).

Innanzitutto, la tua velocità viene dal tuo sprint precedente, o talvolta da una media di alcuni Sprint recenti (Meteo di ieri) e non una media di tutti gli sprint passati. Ovviamente, se non disponi di dati storici del tuo team o della tua azienda, devi trovare un valore ragionevole per il tuo primo sprint. Al tuo secondo sprint, prendi i punti della storia completa nello sprint. Se lo dovessi rappresentare graficamente, potresti vedere delle variazioni nei primi sprint (ad esempio, 17 nel primo sprint, 22 nel secondo, 26 nel terzo, 24 nel quarto). Ciò è prevedibile quando normalizzi il tuo lavoro di squadra e il processo di stima, oltre a comprendere meglio il progetto (tecnologia, dominio).

Questo non vuol dire che non ti adegui. Ad esempio, se hai una settimana che è una settimana festiva, assicurati di tenere conto della vacanza in cui il lavoro è chiuso. Se sai che i membri del team stanno andando in vacanza, organizza meno persone che lavorano. Naturalmente, accadono anche eventi non pianificati, ma puoi spiegarli in una retrospettiva sullo sprint e puoi decidere in che modo influenza il numero di punti della storia che porti alla prossima sprint.

Per quanto riguarda cosa fare, "non riescono a completare lo sprint" è diverso da "non abbiamo completato tutte le storie". Per me un fallimento di uno sprint significa che alla fine non hai prodotto un prodotto potenzialmente spedibile: nessuna delle tue storie è completa, non hai una build, non puoi dimostrare alcun valore aggiunto al cliente o utenti.

Qualunque cosa tu faccia, non dovresti lavorare in ritardo o eccessivo nel tempo. Questo è chiamato ritmo sostenibile ( Agile Alliance , Scrum Alliance ).

Gli indicatori che potrebbero esserci problemi sono se:

• Il tuo team non sta lavorando a un ritmo sostenibile. Devi fare gli straordinari per completare i punti della storia previsti per uno sprint. Riduci i tuoi sprint per completarli in tempo senza la pressione aggiuntiva.
• La tua velocità non si normalizza nel tempo. Nessuno si aspetta che la velocità non cambi mai, ma se noti picchi o oscillazioni, gestisci quelli nelle tue retrospettive sullo sprint. Scopri cosa li sta causando e affronta le cause alla radice.

La metodologia agile varia da un'azienda all'altra, in una implementazione potrebbe essere molto diversa dall'altra. Ho lavorato sotto Agile con due aziende. Nella prima compagnia in cui prendevo, prendevano le loro metriche piuttosto seriamente, nella seconda società per niente. Quindi, per quanto ne sai, nessuno presta attenzione alle tue metriche.

Detto questo, sembra che ti preoccupi di non raggiungere i tuoi obiettivi di sprint o cosa succede quando hai una stima imprecisa. Penso che questo tipo di preoccupazione e prospettive sia comune, ma non è particolarmente importante. Agile, soprattutto, è un sistema di sviluppo software che fa alcune cose:

1. Mantiene gli sviluppatori in movimento
2. Aumenta la trasparenza
3. Permette di riflettere e migliorare gradualmente il processo

Alla fine della giornata, se si stima male uno sprint o si fallisce uno sprint, non è proprio un grosso problema. Le persone che sono al di sopra del tuo team nella tua azienda sono probabilmente più preoccupate che il tuo team si muova costantemente e che i progetti vengano portati al loro logico completamento.

Come individuo con Agile dovresti preoccuparti di quanto lavoro stai effettivamente completando in riferimento al resto della tua squadra. Se sei nuovo, non puoi aspettarti di essere troppo produttivo, ma a un certo punto del tuo rapporto di lavoro dovresti essere alla pari con almeno un po 'della tua squadra. Se non stai producendo lavoro, non stai davvero facendo il tuo lavoro.

La mia comprensione della velocità media e degli impegni di sprint è corretta?

La tua velocità media è perfetta. Nella mia esperienza, questo è molto utile per le stime a lungo termine del completamento - supponendo che abbiate un ampio arretrato; ma non utile per gli impegni di pianificazione dello sprint.

Il processo che ho visto seguito per la pianificazione dello sprint è quello di estrarre storie dalla cima del backlog e lasciare che il team decida se possono realizzarle. I team hanno deciso questo sulla base della sensazione di intestino, abbattendo le attività di 1/2 giornata, la pressione del proprietario del prodotto, l'allineamento con un obiettivo di sprint, la migliore ipotesi (basata sulla velocità) o una combinazione di tutti.

Occasionalmente il Product Owner ha permesso di saltare un paio di articoli in modo da poterne aggiungere altri.

A volte il team e il proprietario del prodotto concordano preventivamente gli articoli stretch su cui spostarsi.

Questa è un'ottima domanda ed è molto importante per il miglioramento dei team. L'argomento è ingannevole ed è ampiamente frainteso. Lo scopo originale del racconto della storia era quello di trovare un metodo rapido e accettabilmente accurato per stimare il livello di sforzo (LOE) necessario per completare la funzionalità definita nelle storie. L'obiettivo generale: fornire ai team un metodo di PREVISIONE o prevedere il tempo necessario per completare uno sforzo (come un progetto). La tua comprensione di Velocity è corretta: sono i punti MEDI per Sprint completati (veramente FATTO). Quindi, se hai un progetto da consegnare, ed è di 250 punti e il tuo team ha una media di 25 punti per sprint, il progetto prenderà circa 10 sprint, più o meno un tempo di buffer.

Alcuni luminari, come Ken Schwaber, suggeriscono che la velocità e i punti vengano utilizzati solo per le previsioni a medio e lungo termine. Suggeriscono di utilizzare le ore di attività come un secondo "controllo di integrità" su cosa si può effettivamente fare in uno sprint. Quindi la quantità di punti in ogni sprint può variare a seconda della capacità. Altri (incluso me stesso), credono che una squadra matura si sistemerà in un modello di dimensionamento molto coerente che può prevedere con precisione la capacità, e alla fine le ore di attività diventano un inutile onere aggiuntivo. (È fondamentale esibirsi per i nuovi team per almeno 6-12 sprint, IMHO, fino a quando la comprensione dei punti e il dimensionamento della trama da parte della squadra siano accurati.)

Il tuo primo piccolo errore è che hai detto che il team dovrebbe conoscere la velocità e portare così tanti punti della storia. In realtà, gli allenatori incoraggiano le squadre a dedurre dal 10% al 20% e invece si impegnano * a quel livello. Quindi, se la tua squadra tende a completare 25 punti per sprint, non riempire lo sprint a 25 punti, ma piuttosto fermati da 20 a 22 punti. Ricorda: è perfettamente FINE portare storie quando l'altro lavoro è fatto. Quindi potresti "impegnarti" a 22 punti e completare 28. È grandioso. Fai solo attenzione a non incoraggiare la squadra a "sandbag" e costantemente impegnata. Non c'è niente di sbagliato nello stretching per vedere se possiamo fare di più.

Ora, al tuo punto sulla varianza tra gli sprint. È un modello molto comune (ma NON OTTIMALE) vedere una squadra che completa 20 punti uno sprint, quindi 50, quindi 22, quindi 45, quindi 15, quindi 60. Se si calcola la deviazione, potrebbe mostrare oscillazioni del 50% al 100% dopo lo sprint. Perché le squadre completano solo 15 punti in uno sprint e poi 60 nel successivo?

Potrebbe significare che il team non sa davvero cosa possono fare. (Ehi, abbiamo completato 50 punti nell'ultimo sprint, possiamo farlo di nuovo in questo sprint).

OPPURE, potrebbe indicare che i proprietari dei prodotti stanno costringendo il team a impegnarsi eccessivamente o stanno aggiungendo lavoro dopo l'inizio dello sprint, ecc. Questi sono solo alcuni degli ANTI-MOTIVI che potrebbero causare questa oscillazione selvaggia nei punti completati.

Questa misura di prevedibilità è importante per i maestri della mischia da osservare e portare all'attenzione del team. Spesso, il motivo per cui hanno completato alcuni punti in uno sprint e poi molti punti nello sprint successivo è quello che io chiamo "ROLLING WAVE OF INCOMPLETE WORK". Ecco un modello molto comune:

Il proprietario del prodotto è sotto pressione per rispettare una data. Quindi il team sente il bisogno di provare a fare molto lavoro. Iniziano come una nuova squadra e non sono sicuri di cosa possano effettivamente fare.

Quindi sprint 1, pianificano lo sprint e come sono in fase di formazione, non possono completare tutto il lavoro. In effetti, hanno un lavoro più incompleto del lavoro svolto. Il lavoro incompleto è INIZIATO ma INCOMPLETO. Viene spostato allo sprint successivo e questa volta hanno svolto più lavoro che incompleto. Al prossimo sprint, quel grande carico di lavoro incompleto si riduce a FATTO e la fiducia della squadra aumenta.

Il proprietario del prodotto è entusiasta e quindi aumenta di nuovo il carico. Alla fine di questo sprint, hanno un'enorme quantità di lavoro incompleto e una quantità deludente di lavoro FATTO.

Qui inizi a vedere WAVES of Done vs Incomplete alternando sprint dopo sprint. Se i team non si rendono conto di ciò che sta accadendo, questo schema può continuare per mesi. Ma in media completano circa 24 punti per sprint. Quindi cosa succede quando smettono di impegnarsi troppo?

Noterai che ANCORA completano da 24 a 26 punti, ma il lavoro di riporto è ridotto. Ora, invece di essere sopraffatto dal tentativo di completare una quantità impossibile di lavoro, che distrugge anche il morale del team, il team può iniziare a migliorare i propri processi.

Nel corso del tempo, la velocità inizierà ad aumentare, senza le enormi oscillazioni nel lavoro Done-vs-Incomplete.

Se non concedi alla squadra un po 'di "tempo libero", non avranno MAI il tempo di eseguire lavori che li renderanno più snelli, più veloci, migliori. Dev-Ops, per esempio, non può accadere. Test Automation - Chi ha tempo per questo !? Ma queste sono esattamente le cose su cui i team devono lavorare in modo da poter aumentare la velocità.