È possibile cambiare la sequenza usata in Planning Poker, per alcune storie, si pensa che quando le storie diventano più grandi contiene più incertezza ma le storie hanno stime quasi esatte del tempo e queste stime non scendono in due limiti definiti dalla serie di Fibonacci.
Sequenza di Fibonacci viene scelta perché non esiste un'estrapolazione lineare tra gli incrementi nella sequenza e aiuta a fermare l' ancoraggio psicologico sui numeri in base ai valori su entrambi lato.
La stima non riguarda solo il tempo.
È un composto di Tempo / Complessità / Rischio come inteso dal team. Sì, potrebbe essere uno sforzo di 30 minuti per un membro della squadra, ma 3 ore per chiunque altro nella squadra. La maggior parte del tempo sarà una delle 3 persone che lavorano sul compito.
Le storie dovrebbero essere classificate relative l'una con l'altra. I numeri nella sequenza di Fibonacci scoraggia dicendo cose come "La storia A è due volte la storia B" e incoraggia "La storia A è più simile alla Storia X" o "Storia A è più di Story B ma meno di Story X " poiché i numeri diventano sempre più piccoli su una scala non lineare.
Alcuni membri del team graviteranno su tutto ciò che ritengono essere un 3 , 5 o 20 e non si sposteranno mai da quei numeri perché vengono ancorati a 3 e 20 come superiore e inferiore limiti nella loro testa. Il 5 è il loro numero compromesso quando sono obbligati a farlo, perché tutti sono generalmente eccessivamente ottimisti. Fornire stime realistiche o pessimistiche; pensano che li faccia sembrare cattivi in qualche modo indefinibile. Ciò che li rende davvero brutti è il fatto di avere sempre dei lati bassi sbagliati e di perdere costantemente impegni e scadenze a causa di ciò.
Sembra che tu debba far sì che il team legga su come si suppone che Planning Poker lavoro , cosa significano realmente i numeri nel contesto della stima.
Fibonacci è solo una linea guida. È un modo graduale di fare stime approssimative e di evitare discussioni. Sarebbe un peccato trascorrere un tempo significativo a discutere (oa discutere) se una storia è in realtà 15 o 16 punti. Questa è solo una differenza del 6%. Allo stesso modo, se la mia squadra trascorre più di un minuto o due a discutere se una storia è un 3 o un 5, segnerò 4 nel software.
Inoltre, è improbabile che la tua capacità di stimare con precisione gli span più di un ordine di grandezza. Se assegni un 1 ad alcune storie, un 13 è davvero sul punto di essere troppo grande. Avevo una regola con la mia squadra che ogni storia più grande di 13 doveva essere suddivisa, ma alla fine hanno iniziato a farlo anche per i 13. Non abbiamo quasi mai nulla di più grande di un 8.
Se il tuo incontro di stima è lungo o controverso, stai andando troppo lontano nei dettagli. I punti storia sono stime veloci e approssimative, non cercare di renderle esatte. La mia regola generale è che occorrerebbero 15 minuti per sviluppatore per stimare uno sprint di due settimane. Un'ora per una squadra di quattro. Non dedicare più tempo a questo.
C'è almeno un motivo in più per cui non vuoi cambiare la sequenza: perché tratterà troppo l'attenzione sul tentativo di ottenere previsioni accurate invece di stime approssimative, che è quello che la storia che punta dovrebbe darti.
Sono un manager di persone e un errore che abbiamo commesso in precedenza è stato quello di mettere molta enfasi su punti, velocità, ecc. I nostri ingegneri, rendendosi conto che i punti erano importanti per la gestione, sono stati incentivati a massimizzare detti punti in modo tale da inserito nei dibattiti su di loro. Questa energia è uno spreco completo per il processo di sviluppo del prodotto e dovrebbe essere ridotta / eliminata.
Non credo che i punti siano terribilmente utili nel tentativo di ricavare programmi a breve termine. Dopo una mezza dozzina o più di sprint con la stessa squadra (s)? Allora sì, la gestione può estrapolare supponendo che ci sia un backlog ben curato, che è di per sé più facile a dirsi che a farsi.
Vuoi ingegneri che discutono su punti o che fanno cose fatte? La tua scelta in base a ciò che decidi di sottolineare.
No, non dovresti cambiare la sequenza per alcune storie di utenti. Usa la stessa sequenza per l'intero progetto. La sequenza di Fibonacci è usata perché descrive l'incertezza crescente con la complessità delle storie.
La sequenza non ha nulla a che fare con la stima del tempo! È la stima della complessità / dimensionamento. Non stimiamo il tempo per le storie. Misuriamo solo quanti punti della storia abbiamo completato negli sprint precedenti e usiamo quella misura per il calcolo della nostra velocità prevista.
Se ritieni che la tua storia utente non sia un limite inferiore, devi sempre scegliere il limite superiore perché hai già mostrato incertezza con limite inferiore. Se ritieni che la stima delle dimensioni porti a grandi storie di utenti con molta incertezza, è il momento di parlare con il proprietario del prodotto (in realtà dovrebbe iniziare perché vede che le sue storie utente non sono abbastanza specifiche dalle tue stime) e dividere quelle storie in e meglio definito.
Leggi altre domande sui tag agile