Stima del tuo arretrato

Le stime non sono aggiornate. Raccogliamo più informazioni e apprendiamo nuove cose e alcuni lavori sembreranno più semplici di quanto non fossero stati una settimana fa e alcuni sembreranno più difficili.

Perché pensi che sia un problema?

Una stima non è altro che un'ipotesi istruita, basata su tutte le informazioni a tua disposizione in un dato momento. Può essere cambiato Se ritieni che i lavori che comportano l'accesso ai file richiedano sempre più tempo di quanto stimato a giugno, aumenta la stima su tutti i lavori che, a tuo avviso, implicano l'accesso ai file che hai stimato a giugno. Ricalcola qualsiasi altro lavoro che implichi l'accesso ai file che hai stimato tra.

Oppure, quando l'azienda decide di aggiungere qualcosa allo sprint imminente, se la guardi e pensa "Dobbiamo essere pazzi quando lo abbiamo stimato!" quindi non abbiate paura di dire al proprietario del prodotto che. Mantiene le loro aspettative sotto controllo.

Il fatto che le stime cambieranno non è mai una scusa per non valutarle ora. Se non lo fai, non vedrai mai quel piccolo lavoro con benefici economici di media impresa tra i massicci posti di lavoro con enormi vantaggi economici.

Cambierà. Va bene.

Molto probabilmente il tuo backlog non sarà aggiornato durante e dopo ogni singolo sprint. Questo è il motivo per cui il grooming degli arretrati è importante. Il tuo PO dovrebbe vederlo insieme all'aiuto del team.

Se il tuo backlog è gestibile, è buona prassi riconsiderare la totalità di esso durante le riunioni di pre-pianificazione / pianificazione, per fornire una panoramica aggiornata più . Insieme a una velocità ben calcolata e stabilita, questo dovrebbe essere sufficiente per fornire agli stakeholder una panoramica di alto livello del progetto e del suo futuro - purché accettino la natura iterativa dello sviluppo agile.

La nostra pratica era di stimare le storie man mano che venivano create (se possibile) e di aggiungere un flag al numero di fib per indicare che avrebbe dovuto essere ridimensionato più vicino all'implementazione.

Nel nostro caso, la bandiera era a .1. (cioè 13.1 significa che "pensiamo che questo è un 13, ma dovremmo rivisitarlo più tardi.)

Quanto in futuro dovresti stimare dipende molto dalle esigenze della tua azienda.

Se il proprietario del prodotto desidera sapere quando è possibile prevedere la caratteristica X, è necessario una stima della caratteristica X e di tutte le funzioni che la precedono nel backlog.
Se il proprietario del prodotto vuole sapere che cosa può probabilmente pubblicare per le vendite natalizie, è necessario stimare le storie fino a quando non ne hai abbastanza per riempire gli sprint fino ad allora.

Detto ciò, le stime non devono tutte essere ugualmente dettagliate e non devono essere espressi nella pietra . Il backlog del prodotto dovrebbe contenere approssimativamente due sprint di storie che sono completamente dettagliate e in cui il team ha una ragionevole fiducia nelle stime. Qualsiasi storia che vada oltre può fare con meno dettagli (maggiore incertezza) e stime che sono corrispondentemente meno sicure. Man mano che andrai avanti nel tempo, è probabile che le storie diventino più grandi (più simili a epiche) con stime adeguate. Questo non è un problema, dal momento che quelle storie e le loro stime saranno / saranno rivisitate man mano che si avvicinano all'implementazione e le conoscenze su di esse crescono.

Il motivo per avere due sprint di storie completamente stimate è di ridurre il carico di lavoro durante la pianificazione dello sprint (non è necessario valutare anche le storie) e assicurarsi che il team possa riprendere un nuovo lavoro dal backlog se si scopre che hanno tempo mancante alla fine dello sprint attuale.

Il motivo per cui non si calcola la stima in pietra è perché dovrebbero essere usati solo come aiuto per la squadra per determinare quanto lavoro stanno impegnando per uno sprint. L'unica cosa che dovrebbe contare alla fine della giornata è se la squadra ha fatto bene al loro impegno.