In cui nella metodologia mischia si definisce l'approccio / concetto per un determinato compito

In generale, dovresti aver già guardato le storie e avere un'idea di una stima o di quali ostacoli potrebbero esistere e devono essere discussi prima della riunione di pianificazione. Questo processo fa parte di grooming del backlog . Questo può o meno comportare un incontro a riguardo. Dovresti anche stimare oltre lo sprint corrente, ma puoi rivedere le stime nella riunione di pianificazione in cui l'attività verrà aggiunta allo sprint se hai realizzato qualcosa dal momento che la storia è stata stimata per l'ultima volta.

Se una storia risulta essere sottostimata in modo significativo dopo essere stata aggiunta allo sprint, è necessario includerla chiaramente nella prossima riunione in piedi. Può darsi che qualcun altro abbia la capacità di aiutare o di prendere altre storie per darti più tempo. Se non esiste alcuna capacità aggiuntiva, può essere opportuno smettere di lavorare sulla storia in modo che le altre storie non siano influenzate (e di solito, se qualcosa è sottostimato in modo significativo, è necessaria comunque più comunicazione). [ modifica ] Il rango dello stack (e la comprensione da parte del team delle esigenze aziendali e delle dipendenze delle attività) dovrebbero essere presi in considerazione nel decidere quali storie potrebbero dover essere eliminate. Invece di abbandonare la storia distorta, potrebbe essere più sensato far cadere altre storie per liberare la capacità. È certamente utile per ottenere il contributo del proprietario del prodotto nel fare questo trade-off, anche se è la squadra che decide. Questo, ovviamente, significa che "fallisci" lo sprint. Nella retrospettiva dello sprint, dovresti discutere perché la storia è stata sottostimata, come potresti stimare meglio la storia in futuro e se e come avere capacità per storie stimate in modo errato.

Ciò che non dovresti fare è uccidersi cercando di completare la storia. Ciò porterà a travisare la velocità e la capacità del tuo team e incoraggiare future sottovalutazioni.

Una soluzione comune a questo problema è di avere una storia più breve separata chiamata design spike . È qui che un membro del team esplora i possibili progetti, magari provando alcune prove manuali del concetto, quindi documenta i risultati e le relazioni al resto del team. Si assegna un po 'di tempo per questo nella precedente iterazione.

L'output di un picco di progettazione è generalmente una stima migliore, insieme a una migliore comprensione dei rischi e delle dipendenze. Di solito il tempo che passi su un picco di design viene salvato nella tua storia principale, spesso di più.

L'idea di base è che qualcuno della tua squadra avrebbe dovuto dedicare una quantità sufficiente di tempo a pensare al problema prima di pianificare, in modo che potessero essere solo gli esperti e riassumere il resto del team. Non sarai mai in grado di esplorare efficacemente un problema nuovo di zecca nel corso di una riunione. In un modo o nell'altro, è necessario trovare il tempo per esplorare il problema prima della riunione di pianificazione. Se un picco di progettazione non funziona per il tuo team, usa le tue retrospettive per valutare e correggere.

Se posso, rivolgerò questa domanda a testa in testa: fino a che punto ti rendi conto che la stima era sbagliata?

Facciamo un esempio: stima che una storia mi richiederà tre giorni. Due giorni dopo, mi rendo conto che è probabile che ci vorranno sei giorni.

Quindi chiediti, se mi ci sono volute 16 ore per capire che è un compito di sei giorni, quanto tempo impiegherebbe il team a risolvere questo problema quando discuterà, piuttosto che implementarlo? Ignora il problema "uomo-mese mitico" e supponiamo che un team di quattro persone possa risolverlo in quattro ore.

Se passassi quattro ore su ciascuna storia, sarebbe necessario un incontro di 40 ore per arrivare a un preventivo affidabile!

Chiaramente, sto giocando con i numeri qui, ma il punto è che stimare è un'altra parola per "indovinare". Devi scendere a compromessi tra non perdere tempo nei dettagli e finire con stime sbagliate. Una soluzione comune a questo è esaminare i tempi reali rispetto alle stime nella retrospettiva e imparare da questo e aggiustare le stime verso l'alto di conseguenza, o applicare un "fattore fondente" alle stime per ottenere un indicatore forse più accurato di il tempo probabile L'altra opzione (che è un hard-sell molto difficile) è adottare l'approccio "senza stime" ...