Rivalutazione della mischia delle storie


14

Ogni giorno, dopo lo stand-up , io e il mio team aggiorniamo le nostre stime per ogni storia. Ho la sensazione che ci sia qualcosa di sbagliato nel modo in cui lo facciamo, quindi ho bisogno del tuo aiuto.

Ecco come facciamo:

Storia Una stima: 24 ore (8 ore al giorno - utilizziamo "giorni ideali" come misura)

  • Giorno N: lo sviluppatore inizia a lavorare sulla Storia A al mattino (8 ore di lavoro completate entro la fine della giornata)
  • Giorno N + 1: rivalutazione Storia A = 16 ore (un giorno lavorativo estratto dalla Storia A, dal giorno N)
  • Giorno N + 2: rivalutazione della Storia A = 8 ore (un giorno lavorativo estratto dalla Storia A, dal giorno N + 1)
  • Giorno N + 3: la storia A dovrebbe essere terminata ormai. Ma non lo è. Lo sviluppatore ritiene che ci vorranno altre 3 ore per terminare. Aggiorniamo la storia sulla lavagna e il burndown di conseguenza.
  • Giorno N + 4: la storia A ha impiegato l'intera giornata per essere terminata anziché solo 3 ore! Adesso è fatto. La differenza, 5 ore, è completamente non presa in considerazione nella nostra pianificazione.

Come dovremmo rivalutare quotidianamente le nostre storie?


hai provato a regolare il fattore di messa a fuoco? Non ho ancora Grok come esattamente si correla con le stime, ma in progetti di mischia ho partecipato, cadere del 10% è stata in molti casi sufficienti per affrontare le stime perse
moscerino

Risposte:


5

La differenza, 5 ore, non è completamente presa in considerazione nella nostra pianificazione.

Sì, viene contabilizzato implicitamente perché le seguenti attività sono ritardate. Se ci fosse un grafico di burndown solo per quello sviluppatore, noteresti che la curva è rimasta "piatta" per un giorno mentre sarebbe diminuita se lo sviluppatore l'avesse terminata abbastanza presto per intraprendere un'altra attività.

Non c'è niente di sbagliato nel modo in cui stai rivalutando durante la riunione quotidiana, la rivalutazione riguarda più il capire se possiamo farcela per la fine dello sprint che non il monitoraggio dell'esatto ritardo di ogni attività. Tutto ciò di cui hai bisogno in Scrum per poter adattare il tuo piano su base giornaliera è qualcosa che indica i progressi di Sprint e quanto sei lontano dal raggiungimento dell'obiettivo Sprint (in genere, un grafico di burndown).


7

La domanda che dovresti porre è: dovremmo rivalutare le nostre storie?

Direi che dovresti consentire all'Agile "magia" di bilanciare le tue sottovalutazioni e sovrastime su un'iterazione quando calcoli la tua velocità per il prossimo (che è l'unica ragione per correggere un valore). Vedi la stima e la pianificazione agili di Mike Cohn per maggiori informazioni.

Tuttavia, c'è un caso in cui dovresti rivalutare: dove qualcosa che hai imparato su una categoria di lavoro regola tutte le stime future.

per esempio. Se si stima che l'aggiunta di una colonna a un database richieda un'ora ideale, ma risulta che occorrono 3 ore a causa di un fattore che nessuno ha considerato e sembra che quel fattore si applichi ogni volta che si aggiunge un campo al database quindi tutte le stime per lavori di quella natura dovrebbero essere adattate, inclusa quella su cui stai lavorando.


3

Quello che ho trovato più efficace è:

  • Taglia le storie per punti (o t-shirt.)
  • Rivalutare qualsiasi storia nel backlog del prodotto in qualsiasi momento (ma soprattutto proprio prima della pianificazione dello sprint.)
  • Non rivalutare le storie in programma per questo sprint - sentiti libero di sollevare preoccupazioni in stand-by, ma non modificare le stime.
  • Usa il tempo di ieri per programmare gli sprint

Se le storie stanno entrando nello sprint con stime fasulle, le ri-stime di pianificazione pre-sprint ti permetteranno di risolverle prima che diventino un problema. Se le storie richiedono più tempo del previsto perché la squadra è troppo ottimista, il clima di ieri ti terrà in pista.

Le rivalutazioni quotidiane di ciò che rimane tendono ad essere totalmente fasulle, come hai descritto nella tua domanda. Il lavoro completato / rimanente è un numero falso progettato per far sembrare che tu stia lavorando "abbastanza duramente". Molto meglio è chiedere "Quando pensi di aver finito" e chiarire che se c'è un problema con una storia, il team farà un passo avanti per aiutare.


La stima del lavoro rimanente non è esattamente la stessa di "Quando pensi di aver finito"? Per quanto riguarda il lavoro completato, sono d'accordo con te, non abbiamo davvero bisogno di misurarlo se non in termini binari di "storia / compito svolto / non fatto".
guillaume31,

1

Penso che questo non sia un problema. Piuttosto, potrebbe essere la mancanza di esperienza. Più segui la mischia, più gli sviluppatori si abituano a fornire stime più precise. Questa è la nostra esperienza di implementazione della mischia dopo 5 mesi.

Nella pianificazione delle sessioni di poker , i nostri sviluppatori hanno suggerito stime molto diverse per ciascun PBI e per ogni attività nel primo sprint. Tuttavia, ora, siamo quasi uguali su tempo e stima. Da quanto tempo usi la mischia? Se non così tanto, dagli un po 'di tempo. Ma se è molto tempo, allora come suggerito da @pdr, considera l'aggiunta di un margine extra per le attività con rischi più elevati . Ad esempio, ogni volta che il nostro team desidera creare una parte dell'interfaccia utente del browser incrociato, passiamo la nostra stima. Pertanto, moltiplichiamo sempre la stima delle attività tra browser per un fattore per essere sicuri di poterla coprire.


1

Rivalutare le storie degli utenti impegnati durante lo sprint non ha senso. Ti fa solo perdere tempo. Hai già preso l'impegno e non importa se fai una nuova stima o meno.

La diversa situazione riguarda le storie degli utenti che non sono impegnate nello sprint corrente. Di tanto in tanto è bene effettuare una nuova stima (non più di una volta per sprint prima della pianificazione). Le situazioni in cui può essere ragionevole rivalutare possono essere:

  • Il proprietario del prodotto ha modificato qualsiasi user story
  • Il proprietario del prodotto ha diviso o unito qualsiasi user story
  • Il proprietario del prodotto ha aggiunto la user story
  • Hai qualche conoscenza aggiuntiva che non era disponibile durante l'ultima storia dell'utente
  • Hai scoperto che alcune storie utente sono correlate e hai già fatto parte di un'altra non ancora impegnata
  • eccetera.

Non è necessario rivalutare necessariamente ogni user story ma è possibile. Per una rivalutazione completa di solito è necessario un metodo rapido. Pianificare il poker può essere dannatamente lento, inefficiente, noioso e talvolta anche impreciso se si prendono in considerazione più di 10-20 storie. L'alternativa può essere la stima magica .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.