Come stimare le attività in mischia?

Francamente, penso che se stai facendo questa domanda, non sei davvero convinto dell'uso della pianificazione sprint.
Il punto della pianificazione dello sprint è quello di portare la squadra in uno stato in cui si sentano a proprio agio nel commettere un determinato set di storie utente, dove sentono di sapere abbastanza per iniziare. Se ciò richiede un'ora, o 2 di 4 o l'intero giorno è completamente accanto al punto; sarà fatto quando sarà fatto.
Di 'che vuoi accorciarlo e limitarlo a 2 ore. Il fatto che abbiano bisogno di informazioni non cambierà, quindi finirai inevitabilmente con parti di ciò che prima era lo sprint planning, spalmato sul resto dello sprint.
Alla fine, tutto ciò che conta è che il team possa impegnarsi in qualche lavoro e consegnare effettivamente quel lavoro per la soddisfazione di se stessi e degli altri stakeholder. Tutto il resto non ha importanza. Concentrati su ciò che effettivamente fornisce valore, non concentrarti sulle metriche di vanità.

P.S .: non importa quanta letteratura indichi che dovresti stimare i compiti in ore, trovo comunque che sia un'idea orribilmente inutile e controproducente e so che non sono solo in questo.

In your experience, how many tasks are there in a sprint and how long should it take to estimate all of them? (Estimating only half of them doesn't make much sense, does it?)

Questo è un po 'come chiedere quante gocce di pioggia sono in un temporale. Non c'è assolutamente modo di rispondere a questa domanda, anche se parli di due tempeste diverse della stessa dimensione. Non esiste una regola empirica, indipendentemente dalle dimensioni della squadra o dalle dimensioni dello sprint.

Il punto di stimare le ore nei compiti è che il team possa imparare a stimare meglio le loro storie. Ad esempio, considera due storie che hai stimato: una è stimata in 2 e una in 4 o 5. Quando inizi a occupartene ti accorgi che entrambe hanno all'incirca lo stesso numero di ore assegnate alle attività. Che cosa ti insegna?

L'unica regola empirica che penso di poter dare è che, se la tua squadra ha una velocità stabile, non è necessario stimare le attività. Se trovi che la tua velocità è instabile, è probabile perché le tue abilità di stima sono deboli. Puoi rafforzarli suddividendo le storie in attività in fase di pianificazione come un tipo di controllo di integrità per la stima.

Nella tua domanda dici che la tua squadra non è ancora presente, quindi la stima è importante. Se è vero, non preoccuparti del tempo che dedichi a farlo. Ci vorrà tutto il tempo necessario. Stai facendo un investimento nella tua squadra. Sì, all'inizio ci vorrà molto tempo, ma spero che imparerai dall'esperienza. Potresti scoprire che è una perdita di tempo, o potresti imparare che non sei così intelligente nel valutare come pensi.

Ricorda: scrum non è un insieme di regole da seguire, ma un insieme di strumenti per aiutarti a pianificare e organizzare il tuo lavoro. Ogni volta che questi strumenti stanno ostacolando la tua produttività, dovresti smettere di usarli. Assicurati che in realtà interferisca con la tua produttività anziché dare l'impressione di farlo.

assuming a three week sprint with 8 developers means 120 tasks, and taking two hours only for estimations seems to be a bit much to me.

Per me questo significa che 8 sviluppatori impiegano 15 minuti per pianificare le prossime 3 settimane. È troppo? È come un alzarsi quotidiano.

È una stima. Organizza il tuo primo sprint. Prendi buone note e misure. Il tuo primo sprint sarà probabilmente lontano dal marchio. Se questo è un problema, metti il tempo e i passaggi necessari per migliorare quello successivo. Le attività richiedono più tempo del previsto? Ogni dev può svolgere tutte le attività in uno sprint determinato come previsto?

Sii aperto e onesto su ciò che è stato veramente fatto e quanto tempo ci è voluto. Se le persone hanno paura, faranno solo il gioco del sistema. Baserai le tue decisioni di pianificazione su dati errati. Se troppe attività richiedono più di un giorno (o qualsiasi altra cosa si pensasse dovrebbero prendere), determinare se sono state suddivise in pezzi abbastanza piccoli.

I tuoi sviluppatori potrebbero non avere a disposizione 8 ore al giorno per lavorare su attività o qualsiasi altra cosa vogliano sentire la gestione dei numeri magici per ritenere di avere un giorno intero di lavoro per una paga intera.

Sarebbe una cosa così orribile da scoprire dopo 2 settimane che hai completato uno sprint di 3 settimane o hai completato solo il 75% delle attività alla fine dello sprint? Impara dall'imprevisto (questa è una stima, quindi non soffermiamoci su di loro e chiamali errori).

L'obiettivo è rendere felice il cliente nel contesto di ciò che desidera fare nel tempo e nelle risorse date. Non è per aspirare la volontà di vivere da ogni programmatore che devi completare questo progetto.

Quindi per rispondere alla tua domanda: fai del tuo meglio per stimare il tuo primo sprint. Impara da esso e aggiusta quello successivo. Ripeti.

La mia opinione personale è che la stima delle ore di lavoro è sprecata tempo nella pianificazione sprint. In generale, le stime sono sbagliate e non ho alcun valore nel riferire su di esse. Tuttavia, molti strumenti di tracciamento delle attività agili usano queste ore per generare burndown, quindi abbiamo bisogno di qualcosa .

Per risparmiare tempo, ho iniziato a seguire questa procedura:

1. Imposta ogni attività creata su "1 ora" non appena viene creata l'attività.
2. Man mano che gli sviluppatori affrontano le attività durante lo sprint, se pensano che occorra più di un'ora sull'attività, possono aggiornarlo con un valore più realistico.
3. Man mano che le attività vengono completate, i rapporti di burndown vengono aggiornati sulle ore restanti.

Avrai ancora la possibilità di vedere come stanno andando i progressi e se sei sulla buona strada, ma puoi usare il tempo di pianificazione dello sprint per azioni più preziose come capire le storie e capire quali compiti devono essere svolti.

TL; DR

[H]ow many tasks are there in a sprint and how long should it take to estimate all of them?

La tua domanda non ha una possibile risposta canonica. Sebbene sia possibile utilizzare alcune regole empiriche per calcolare un limite superiore ragionevole per il volume delle attività, non esiste un indice di conversione universale per le storie in attività o le attività in ore lavorative.

Ad esempio, una regola empirica comunemente accettata è che un'attività deve essere dimensionata tra una mezza giornata e due giorni in modo che il ciclo di feedback completato / non eseguito rimanga stretto. Le squadre possono e violano questa regola empirica, in quanto non è un requisito di struttura, ma le squadre di maggior successo con cui ho lavorato seguono tutte lo spirito di questa regola.

Attività per Sprint

I know the answer depends on sprint length and team size, so let's assume 8 developers and three weeks.

Questo è assiomaticamente sbagliato, dal momento che il numero di compiti dipende dal numero di storie e dalla quantità e granularità delle attività decomposte di ogni storia. Ciononostante, può calcolare un limite superiore approssimativo per il controllo di integrità.

Se si assume a priori che:

• ogni attività richiede un solo sviluppatore (spesso questo non è il caso)
• Il 30% dello sprint è utilizzato dall'overhead del framework (questo numero varia in base alla lunghezza dello sprint)
• non stai applicando alcun fattore fudge per il fatto che le ore di lavoro produttive sono generalmente < = 6 ore per giorno lavorativo