Penso che ti stia bloccando troppo in matematica e perdi di vista ciò che è importante.
La ragione per cui fai tutto questo è capire quanto lavoro deve svolgere il team in uno Sprint e impegnarsi a farlo. Quando sei sicuro di avere una mano su questo, allora puoi iniziare a estrapolare in modo significativo quanti Sprint ci vorranno per ottenere un certo modo nel PB, anche se questo diventa rischioso perché il PB è una cosa in evoluzione in evoluzione. / p>
Quello che vuoi veramente fare è capire quanti giorni man stimati, o ore uomo, o punti storia, o penny da favola o qualsiasi unità tu voglia usare, che puoi fare in uno Sprint. Non importa nient'altro. Puoi chiamare quella velocità se vuoi, oppure creare il tuo termine che funziona meglio per te.
Il vero problema che hai è capire cosa è successo con le tue stime sull'ultimo Sprint. Perché erano fuori così tanto? Ora questo ti porterà a una delle seguenti conclusioni:
- È stato un caso fortuito e probabilmente non succederà mai più. Elimina i risultati e continua come non è successo.
- Accidenti! Succhiamo a stimare e abitualmente sopravvalutiamo ogni attività. Non cambierà mai. Quindi raddoppia la quantità di lavoro stimato che hai inserito in ogni Sprint.
- Stiamo costantemente sovrastimando il nostro lavoro di un fattore due, quindi dimezzeremo ogni stima andando avanti e lasceremo la nostra velocità stimata allo stesso modo.
- Accidenti! Succhiamo a stimare e miglioreremo. IMHO, questa è la migliore conclusione ma anche quella che ti dà i maggiori problemi di pianificazione. Perché? Perché le tue stime miglioreranno costantemente in accuratezza e la tua velocità è una misura della tua capacità passata di completare le attività stimate. Quindi la tua velocità passata è solo parzialmente pertinente alla velocità che ti aspetteresti di avere in futuro man mano che migliorano le tue tecniche di stima.
Quando abbiamo iniziato a fare Scrum 8 anni fa, ho calcolato di routine il numero di giorni uomo disponibili per il lavoro del progetto Sprint prendendo il numero totale di giorni uomo in cui i membri del team erano nell'ufficio e dividendo per due. Questo ha fatto impazzire il mio capo, perché voleva sapere perché avevamo rinunciato a mezza giornata per ogni giornata di lavoro senza combattere. Ho pensato che fosse aggressivo perché pensavo che sarei stato fortunato se mai avessi avuto circa 1/2 al giorno di lavoro di progetto da parte di ogni membro del team ogni giorno.
Quindi, in sostanza, ho assegnato un fattore di fuoco del 50% in modo casuale, anche se non avevo mai sentito parlare del termine "fattore di attenzione". E questo è stato abbastanza buono da far partire gli Sprint all'inizio della nostra esperienza Scrum. Nel corso del tempo, ho imparato che faremo bene tra 8 e 11 giorni di lavoro del progetto per ogni membro del team per ogni Sprint di 4 settimane. Lo aggiusterò se qualcuno è in vacanza o fuori dall'ufficio per qualche giorno, o se sappiamo che c'è qualcosa che sta succedendo con l'azienda che probabilmente toglierà per un po 'uno dei membri del team dal progetto.
Il nostro team non è omogeneo nei set di abilità (ancora!), quindi in realtà ci occupiamo delle attività a singoli membri o gruppi di membri durante la riunione di pianificazione. Quindi sommiamo tutti i giorni uomo per ogni membro del team. Se vedo un 13, o se vedo un intero gruppo di 11 sulla lavagna, so che abbiamo un problema. Sposteremo le cose se possibile, o lasceremo uscire lo Sprint.
Ma il punto è che non ci sono implicazioni matematiche. Tengo d'occhio se è stato fatto o meno tutto, e se c'è stato un tempo extra per qualcuno, e poi ne discutiamo e adattiamo quando necessario. Non ha bisogno di essere complicato. Vuoi mantenere il progetto andando avanti il più velocemente possibile, ma senza sovraccaricare gli Sprint in modo che le cose non vengano completate.