Quanto ci si può aspettare che le stime siano coerenti?

In realtà i tuoi numeri sembrano avere la tua distribuzione prevista, sebbene sia nascosta dalla scala di log. Potresti ottenere una migliore intuizione con un grafico che illustra la densità, ad es. una trama di violino. Un box-plot può fornire rapidamente alcune statistiche riassuntive che non sono ovvie per i tuoi dati.

Il confronto della mediana potrebbe essere migliore del confronto tra il minimo e il massimo, in quanto la mediana indica "il 50% delle storie 1-SP sono state completate entro X ore". Per la stima delle attività, è previsto che ci saranno valori anomali in entrambe le direzioni. Alcune attività saranno molto più facili del previsto (si verificano occasionalmente per correzioni di errori). Un sacco di compiti richiederà molto più tempo del previsto.

Ma sì, l'alta varianza sembra strana. Ma questo dipende da come gli SP vengono usati da quei team. Per esempio. se i team utilizzano gli SP per classificare i loro compiti in base allo sforzo (una scala ordinale), allora è inutile / non valido per provare a reinterpretarlo come una durata (scala di intervalli). (Vedi: Tipo di dati statistici .) La tua analisi è valida se gli SP sono anche una scala a intervalli, cioè tre 1-SP ci si aspetta che le attività siano tanto impegnative quanto un compito 3-SP.

Potrei considerare di smettere di fare SP e iniziare a stimare in incrementi di {½ giornata, 1 giorno, 2 giorni, settimana}. Sì, sì, questo non è Scrum e il male. Ma consente di formare un ciclo di feedback. Nella retrospettiva, la squadra può passare attraverso le storie completate e confrontare la stima con il tempo impiegato. Il team può quindi discutere quali problemi imprevisti si sono presentati e come possono essere evitati o considerati in futuro. Questo semplice atto di confrontare le aspettative con la realtà dovrebbe portare ad un rapido miglioramento della varianza della stima nel corso di alcuni sprint, assumendo naturalmente che il team è interessato a produrre stime migliori.

TL; DR:

• sì la varianza è un po 'estrema
• il team dovrebbe provare a migliorare il proprio processo di stima durante una retrospettiva, utilizzando stime in tempo reale che lo rendono più semplice
• no, è improbabile che un seminario di stima aiuti in questo senso
• se fai statistiche, per favore fallo un po 'più attentamente

Ora stai osservando solo l'accuratezza della stima stessa. Nella mia esperienza, l'inesattezza è più spesso causata dalle storie degli utenti, piuttosto che dalla stima stessa.

Alcune cose da considerare qui

• Viene svolto più lavoro sulla trama dell'utente rispetto a quanto definito dalla storia stessa (alcune funzionalità aggiuntive per la frutta a basso impatto).
• I criteri di accettazione non sono ben definiti. I criteri di accettazione dovrebbero essere chiari e verificabili. In altre parole, esiste una definizione di pronto?
• Non esiste una definizione di fatto. Includete le revisioni del codice, i test di scrittura, il refactoring, la pulizia del codice nel DoD? È anche incluso nella stima?

A volte trovi storie di utenti come: "Crea una finestra che elenchi questo e questo". Tutti sanno cosa si intende, quindi perché definirlo ulteriormente? Bene, è vago e le persone faranno cose diverse. Se durante il planningspoker le stime dei membri del team sono molto distanti, questo è un buon segno di user story non definite (non sempre)

Ciò che potrebbe aiutare è mantenere un elenco di storie degli utenti dello sprint precedente, in cui il team ritiene che la stima fosse ok. Mostra quell'elenco all'inizio del planningsmeeting, in modo tale che ci sia una linea di base e le nuove storie utente possono essere confrontate con quelle.

La complessità (che è ciò che i punti della storia dovrebbero essere) e le ore trascorse su una storia non sono sempre correlate. È possibile avere un cambiamento estremamente semplice che richiede molto tempo per implementare o un cambiamento complesso che richiede un tempo relativamente breve per implementarli, ma dovrebbe bilanciarsi a vicenda in qualche modo nel tempo e questo sembra essere il caso dell'esempio, la coppia 5 che erano meno di 10 ore per una manciata di 1 che sono più lunghi.

Ci sono alcune cose che possono essere fatte per ottenere stime più coerenti sulla tua squadra. Puoi prendere storie precedenti e usarle come esempio canonico di cosa sia una storia di X point. questo può essere utile perché è generalmente più facile stimare se la storia X è più vicina a Y o Z rispetto alla stima di X a titolo definitivo. Un'altra cosa che mi viene in mente è che il tempo trascorso su storie di tutti i punti sembra estremamente lungo, probabilmente varrebbe la pena discutere di alcuni di questi casi in retrospettive. Sembra che ci siano molte storie da 3 o meno punti che richiedono più di 40 ore per essere completate e penso che sia un buon segno che qualcosa non va bene. Se ci metti un po 'di tempo per indagare su questo puoi avere un'idea migliore se hai dei requisiti scadenti, un certo creep, le persone non ricevono aiuto abbastanza presto, dipendono da team esterni, non rompono abbastanza storie, molti bug che causano il rigetto di una storia più volte o qualcos'altro.