Uno dei miei colleghi ha suggerito di cronometrare quanto tempo ogni membro del team spende per ogni storia di un utente. Questo mi sembra probabile confondimento per il team di sviluppo durante l'iterazione e fuorviante come parametro per la stima della storia nelle future riunioni di pianificazione.
Qualcuno di voi ha esperienza con un tale sistema e qualche idea su quanto possa essere utile o distruttivo?
È necessario avere solo una misura della durata della storia da implementare in modo da poterla confrontare con la stima iniziale. Armati di queste informazioni puoi quindi ottenere stime migliori la prossima volta.
Ad esempio, per questa iterazione decidi che la storia A richiederà 2 giorni e la storia B ne richiederà 4. Tuttavia, in realtà ne bastano 3 per entrambi. Quindi nella prossima iterazione puoi guardare di nuovo le storie rimanenti e ricostituirle in base a queste informazioni. Se ci sono più storie come "A" avrai bisogno di più tempo (o meno), tuttavia se ci sono più storie come "B" avrai bisogno di meno tempo (o più).
Non dovresti registrare il tempo contro le persone nella squadra, ma contro la storia. So che alcuni dicono che non dovresti registrare nessuna volta, ma a meno che tu non abbia sviluppatori perfettamente in grado di ricordare le loro stime dei compiti futuri saranno distorte. Avere numeri ti consente (in una certa misura) di normalizzare le stime.
In Scrum, tutto lo sforzo si concentra sul guardare al futuro. Gli effettivi, quindi, non hanno valore intrinseco. Ciò che è utile sugli actual è usarli per affinare il modo in cui una squadra fa le sue stime.
Anche lì, però, un'analisi dettagliata di come le singole stime utilizzate contro il reale è di scarso valore. In pratica, la maggior parte delle squadre imparano a convivere con la loro accuratezza di stima e popolano di conseguenza i loro Sprint Backlogs.
Per esempio, supponiamo che una squadra abbia abitualmente finito le attività di stima. Pianificano 30 giorni / uomo di sforzi per una squadra di 5 persone su uno Sprint di 2 settimane (5 * 6 (supponendo il 60% di utilizzo dei 10 giorni lavorativi)) e scoprono che tutto viene fatto entro il giorno 4. Quindi quando pianificano il prossimo Sprint, dicono a se stessi: "Bene, siamo stati in grado di completare 30 giorni di preventivi con un sacco di tempo rimasto, quindi mettiamo 60 (stimato) uomo-giorno di attività nel prossimo Sprint e vediamo cosa succede". Col passare del tempo, impareranno come le loro stime si riferiscono a quanto lavoro possono fare in uno Sprint. Non importa quanto siano pessime le stime, a patto che siano coerenti.
Le retrospettive sono il luogo in cui il team si siede e osserva le loro stime e il modo in cui vogliono gestire (o non trattare) la precisione. L'unico fattore importante, tuttavia, è che calcolano la quantità giusta di compiti da inserire nel prossimo Sprint.
L'ho fatto nel mio primissimo progetto Scrum. Non ha fornito alcun valore. Questa tecnica ha senso solo se si desidera riutilizzare tale conoscenza per la stima successiva, ma in tal caso è necessario stimare in ore la granularità (attività) molto bassa che non è possibile.
Lo facciamo sul nostro progetto. I gestori lo adorano, perché hanno fogli di calcolo pieni di numeri. Non ho visto alcuna prova che aiuti effettivamente il progetto a funzionare meglio.
Devi chiedergli perché vuole misurare quanto tempo dedicano alle storie degli utenti.
L'unica ragione valida che vedo è il controllo della produttività. Se davvero desidera calcolare la produttività individualmente in questo modo, è necessario smettere di usare Scrum.
Scrum è centrato sul team, non su quello individuale. Funziona per questo.
Posso immaginare solo due usi:
1) Se mantieni qualche tipo di story point o di complessità per ogni stoyry, puoi ottenere una sorta di media o intervallo di tempo richiesto per ciascun punto di complessità. Questo potrebbe essere utile per stimare le attività future.
2) è possibile calcolare ogni successo di stima empoyeese: il tempo previsto per un'attività v / s il tempo effettivamente impiegato per terminarlo. Non vedo come ciò migliorerà il processo ma può essere usato come ricompensa / punto di penalità durante le valutazioni.
Leggi altre domande sui tag estimation scrum prediction