Scrum rivalutazione di storie

The difference, 5h, is completely unaccounted for in our planning.

Sì, è rappresentato implicitamente perché i seguenti compiti sono in ritardo. Se ci fosse un grafico di burndown solo per quello sviluppatore, noteresti che la curva è rimasta "piatta" per un giorno mentre sarebbe andata giù se lo sviluppatore l'avesse terminata abbastanza presto da assumere un'altra attività.

Non c'è niente di sbagliato nel modo in cui stai rivalutando durante le riunioni quotidiane, la rivalutazione consiste nel capire se possiamo farcela per la fine dello sprint piuttosto che nel rintracciare l'esatto ritardo di ogni attività. Tutto ciò di cui hai bisogno in Scrum per essere in grado di regolare il tuo piano su base giornaliera è qualcosa che indica lo stato di avanzamento di Sprint e quanto sei lontano dall'obiettivo di Sprint (in genere, un grafico di burndown).

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

Direi che dovresti consentire alla "magia" di Agile di bilanciare le tue sotto e sovrastime su un'iterazione quando calcoli la tua velocità per il prossimo (che è l'unica ragione per correggere un valore). Per ulteriori informazioni, vedi Mike Cohn's Agile Estimating and Planning .

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

ad es. Se si stima che l'aggiunta di una colonna a un database richieda un'ora ideale, si scopre che occorrono 3 ore a causa di un fattore che nessuno ha considerato e sembra che quel fattore verrà applicato ogni volta che si aggiungendo un campo al database, allora le tutte stime per il lavoro di quella natura dovrebbero essere regolate, inclusa quella su cui stai lavorando.

Ciò che ho trovato più efficace è:

• Dimensione delle storie per punti (o taglie della maglietta.)
• Rivaluta qualsiasi storia nel backlog del prodotto in qualsiasi momento (ma soprattutto prima della pianificazione dello sprint.)
• Non stimare nuovamente le storie previste per questo sprint - non esitare a sollevare dubbi in stand-up, ma non modificare le stime.
• Utilizza il meteo di ieri per pianificare gli sprint

Se le storie sono che inseriscono lo sprint con stime fasulle, le stime di pianificazione pre-sprint ti consentiranno di correggerle prima che diventino un problema. Se le storie impiegano più tempo del previsto perché la squadra è troppo ottimista, il meteo di ieri ti manterrà in carreggiata.

Le nuove stime giornaliere di ciò che rimane sono tendenzialmente false, come hai descritto nella tua domanda. Il lavoro completato / rimanente è un numero falso progettato per far sembrare che stai lavorando "abbastanza duramente". Molto meglio è chiedere "Quando pensi di aver finito" e chiarire che se c'è un problema con una storia, il team si farà avanti per aiutare.

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.

Nelle sessioni di pianificazione del poker , i nostri sviluppatori suggerivano stime molto diverse per ogni PBI e ogni attività nel primo sprint. Tuttavia, ora, siamo quasi uguali sul tempo e sulla stima. Da quanto tempo usi la mischia? Se non così tanto, dagli un po 'di tempo. Ma se è molto tempo, come suggerito da @pdr, considera l'aggiunta di margine aggiuntivo per le attività con rischi più elevati . Ad esempio, ogni volta che il nostro team vuole creare un pezzo di cross-browser dell'interfaccia utente, passiamo le nostre stime. Pertanto, moltiplichiamo sempre la stima delle attività del browser incrociato per un fattore per essere sicuri di poterlo coprire.

Non è logico rivalutare storie di utenti impegnate durante lo sprint. Ti fa solo perdere tempo. Hai già fatto un impegno e non importa se fai una nuova stima o meno.

La diversa situazione è con le storie degli utenti che non sono impegnate nello sprint corrente. Di tanto in tanto è consigliabile effettuare una nuova stima (non più di una volta per sprint prima della pianificazione). Situazioni per le quali è ragionevole stimare la stima possono essere:

• Il proprietario del prodotto ha cambiato la cronologia utente
• Il proprietario del prodotto dividere o unire qualsiasi storia utente
• Il proprietario del prodotto ha aggiunto la user story
• Hai alcune conoscenze aggiuntive che non erano disponibili durante la storia dell'ultimo utente
• Hai riscontrato che alcune storie utente sono correlate e ne hai già fatto parte un'altra ancora non ancora impegnata
• ecc.

Non è necessario necessariamente rivalutare ogni storia utente, ma è possibile. Per una completa rivalutazione di solito hai bisogno di un metodo veloce. Pianificare il poker può essere dannatamente lento, inefficiente, noioso e talvolta anche inaccurato se si prendono più di 10-20 storie di stima. L'alternativa può essere Stima magica .