Va bene cambiare le stime nel mezzo di un'iterazione?

Abbiamo iniziato a utilizzare Agile / Scrum in un team di 4 sviluppatori. Abbiamo fatto le nostre stime delle storie e abbiamo ordinato le storie Storie con primati nel backlog del prodotto.

Abbiamo iniziato con la stima basata sul punto sulla complessità da 1 a 5, invece del solito 1,2,3,5,8,13 .... e così via

Dopo aver lavorato su un paio di storie, abbiamo ritenuto che alcune delle storie stimate in 4 punti dovrebbero essere solo 2, mentre le altre che sono state stimate in 2 sono molto più complesse e avrebbero dovuto essere valutate come 5. Vorrei conoscere:

Va bene cambiare le stime della nostra storia nel mezzo dell'iterazione?
Va bene usare gli attuali punti di stima da 1 a 5, invece dei soliti 1,2,3,5,8,13 .... e così via

Anche se personalmente ritengo che non dovrebbe essere per entrambi i casi, ma ho bisogno di appoggiarmi poiché la mia comprensione non è molto chiara (qualsiasi buon materiale di riferimento sarebbe buono però!)

project-management agile estimation

— tintin
fonte

Chiedetevi: qual è il vantaggio di passare il tempo a rivalutare la metà sprint? Qual è il vantaggio di passare più tempo a "litigare" su 3 contro 4 contro 5 a grana fine rispetto a un 3 contro 5 approssimativo?

— Hugo,

Risposte:

Va bene cambiare le stime della nostra storia nel mezzo dell'iterazione?

Assolutamente no. Ci aspettiamo che ciò accada. E prevediamo che gli errori si bilancino nel tempo. Modifichiamo davvero le stime solo quando è chiaro che una determinata categoria (ad esempio nuove pagine Web) sarà sempre più complessa di quanto avessimo pensato quando le abbiamo stimate tutte.

Man mano che una storia epica viene suddivisa in storie più piccole (cosa che dovrebbe accadere molto prima dello sprint), potremmo sembrare che adeguiamo la stima originale, ma la definirei raffinazione piuttosto che rivalutazione. Questo perché abbiamo una visione più chiara in quel momento.

L' agile stima e pianificazione di Mike Cohn è un buon libro sull'argomento. Vorrei mettere in guardia dall'usarlo (o da qualsiasi libro "Agile") come una bibbia, ma è un buon punto di partenza da cui affinare il processo.

Parla del modo in cui le stime errate si bilanciano come "magiche", ma sottolinea che lo ha visto funzionare ancora e ancora e ancora.

Va bene usare gli attuali punti di stima da 1 a 5, invece dei soliti 1,2,3,5,8,13 .... e così via

L'uso della serie di punti di Fibonacci è un'accettazione del fatto che più grande è una storia, meno accurata è la nostra stima (vedi il mio commento precedente su Epics).

Ma, se non funziona per te, in particolare se mantieni tutti i tuoi lavori piccoli, non usarli. È una linea guida, non una regola.

Anche il dimensionamento delle t-shirt (SML XL XXL) è molto popolare e sostanzialmente diverso da (1 2 3 4 5).

— pdr
fonte

+1: parlane durante la tua retrospettiva. Stimare nuovamente quando si ridefinisce la priorità all'inizio della primavera successiva. Ecco perché hai sprint. Nessun sovraccarico di gestione durante lo sprint: basta creare un codice.

— S. Lott,

A proposito dell'uso della serie fabonacci, supponiamo che tu sappia che una storia richiederà quasi 3 giorni e il no. dei compiti per fare la storia sono A, B, C. Senti anche che non è molto complesso, ma ognuna di queste attività richiederà 1 giorno ciascuna. Quale stima daresti alla storia?

— tintin,

@tintin: La ragione per usare i punti è evitare di dire cose come "sai che una storia richiederà quasi 3 giorni". I punti sono relativamente arbitrari, ogni lavoro si basa sulla complessità rispetto ad altri lavori (ovviamente dovresti evitare di usare lavori non stimati come base). Tuttavia, si evitano i numeri mancanti, per tenere conto dell'incertezza. Pertanto, se il lavoro B è due volte più complesso del lavoro A e il lavoro A è stato contrassegnato come 2 punti, si contrassegna il lavoro B come 5 punti.

— pdr,

+1 per: più grande è una storia, meno accurata è la nostra stima

— kevchadders il

Va bene cambiare le stime della nostra storia nel mezzo dell'iterazione?

Assolutamente sì, se influirà sulla pianificazione della primavera attuale o futura. Il punto di agile è basare le tue azioni su informazioni il più attuali e corrette possibili.

Se una stima risulta essere così errata che lo sprint corrente non può essere completato nel suo intervallo di tempo, è necessario agire sulla stima rivista, quindi probabilmente vorrai cambiarlo. Se basi nuove stime su quelle vecchie (e in realtà le guardi piuttosto che affidarti alla memoria / all'esperienza), hai bisogno che siano corrette.

D'altra parte, non c'è davvero alcun valore in sé in una stima che sia corretta. Non perdere tempo a fare delle statistiche insignificanti.

— Michael Borgwardt
fonte

Nel nostro caso la stima iniziale è stata grande e il lavoro per questo risulta essere molto meno. Quindi non è che il nostro attuale sprint non sia finito in tempo ma abbiamo tempo extra. Quindi il manager suggerisce di abbassare la stima.

— tintin,

@Michael, questa risposta può essere vera per alcuni processi agili ma la domanda riguarda Scrum. In Scrum, non è consigliabile cambiare i punti della storia dopo la pianificazione dello sprint perché la metrica Velocity del team potrebbe essere compromessa.

— GuyR,

Le stime non riuscite comportano un vantaggio in quanto è possibile utilizzarle per adeguare di conseguenza eventuali stime future. Se si stima troppo a lungo, si tratta di un errore tanto quanto di una stima troppo breve, poiché il risultato sono risorse sottoutilizzate. Il valore nelle stime corrette è che sai che probabilmente stai raggiungendo i tuoi obiettivi di rilascio e che il tuo team è pienamente utilizzato. Pertanto, si basano sempre le stime future sulle esperienze passate, adattandosi in base a ciò che si apprende sulle stime lungo il percorso.

— S.Robins,