Scrum compito sulla stima

Il peccato di sopravvalutazione è probabilmente meno grave di quello della sottovalutazione, perché la squadra sta almeno rispettando i suoi impegni e non contribuendo al caos che può verificarsi quando gli impegni mancano (in particolare quando gli altri dipendono dall'output di una squadra per conto proprio lavoro, come spesso accade).

Come fai a sapere che stanno sopravvalutando / sottoperformando? Stanno passando ore e ore nello Starbucks nella hall? O è solo qualcosa che "senti" in base alla tua comprensione dell'ambito e della complessità del loro output per sprint? Se quest'ultimo, sono gli individui forse più approfonditi nell'eliminazione (o meglio ancora nella prevenzione) del debito tecnico? Hanno una copertura di test migliore rispetto ad altri team? Il loro software è progettato in modo migliore? Rifattorizzano quando necessario?

Non sto difendendo tutte le squadre "lente" - ne ho gestite alcune. Quello che devi sapere prima di agire è perché sono lenti e quali passi possono essere ragionevolmente adottati per aumentare la velocità, senza sacrificare la qualità del lavoro prodotto.

Vorrei mettere in dubbio ogni squadra che ottiene mai lo sprint completato tutto il tempo. Questo non è davvero l'obiettivo. Va bene spingere te stesso anche se questo significa mancarne qualcuno. Puoi sempre regolare. Se riescono a realizzare tutto in tempo verso la fine del progetto, forse lo hanno capito.

Gli sviluppatori stanno per sottovalutare perché:

1. Ci sono serie conseguenze per non riuscire a fare tutto.
2. Vogliono che il progetto duri più a lungo, faccia meno lavoro, ecc.
3. Sono troppo presi dall'intera pianificazione e pensano che debbano essere perfetti. Forse prendono tutto troppo sul serio o letteralmente.

Sono sicuro che ce ne sono altri.

Indipendentemente dal modo in cui un team gestisce se stesso, c'è ancora un business da gestire, quindi ci saranno aspettative su quanto lavoro si lavori. I clienti hanno aspettative. Alla gente piace essere pagato alla fine. Qualcuno che paga le bollette deve esaminare il progetto e determinare se sarà completato in un ragionevole lasso di tempo. In caso contrario, regola i requisiti o regola la squadra.

Qualcuno che sa qualcosa su quanto tempo ci vuole per essere costruito (sembra che tu abbia scoperto questo.) deve rivolgersi al team. Probabilmente un leader in azienda. È qui che arriva la risposta di Jeff Shurt. Puoi identificare perché non stanno tentando di più? È sapere come pianificare, essere troppo preoccupato per non finire uno sprint, essere meno abile o semplicemente dimagrire. Come parte della mischia, non guardi un giorno o uno sprint. Guarda diversi e nota la tendenza.

Forse le persone orarie devono essere divise? Essere in una squadra che sta diventando più completo potrebbe aiutare a spostarli lungo.

@JeffO C'è un altro che voglio approfondire su:

Tesi 1

Questi due programmatori stimano giusto, ma hanno una conoscenza incompleta (Così faccio io).

Questo è un team di due programmatori e quei due programmatori

1. sono molto disconnessi dagli altri team.
2. basano il loro lavoro su un sacco di lavoro straniero che è difficile stimare

Dato che sono solo due persone, può essere più forzato a non comunicare con squadre più grandi perché

1. hanno più sulle loro sholders (50%), quindi non possono andare da qualche parte e chattare
2. sono più di un completatore-finitore (Belbin), molto orientato al compito, non troppo connettivo se non è in grado di risolvere problemi, non vedono alcuna necessità di scambiare con altri team. Sono molto efficaci ed efficienti da soli.

Soluzione:

1. Cambiano il loro posto di lavoro e lavorano come ambasciatori in quei gruppi con cui dovrebbero comunicare di più.
2. Se entrambi non amano questa idea e sono molto perfezionisti, non amano questo cambiamento, forse sono i compiti sbagliati che passi loro? Forse soffrono davvero di questi compiti incompleti di hacking-qualcosa-insieme che ottengono nelle loro user story. Forse le storie degli utenti con un'altra qualità di codice sono migliori?

Tesi 2

Non riflettono sui compiti o l'insieme di compiti non ha molto in comune.

Tesi 3

Hai un problema di comunicazione. (Le persone hanno sempre). Se ti rivolgi a programmers.stackexchange prima di provare a parlare con loro, potresti essere un indicatore. (Non lo so)

Tesi 4

Come mai sopravvalutano? I punti storia non sono unità di tempo. Voglio dire: hanno bisogno di aumentare i punti storia ogni volta per sopravvalutare. Puoi creare una mappatura punto-punto a partire dall'iterazione precedente e prenderla come base per i calcoli temporali.

xxx Questo è tutto speculazione ma mi sono divertito a scriverlo.

Qualunque sia la metodologia, un prodotto fallirà se i partecipanti non sono motivati.

Come Scrum Master, fai parte del team, non sopra. La buona notizia è che rende almeno un membro motivato del team :)

Devi chiedere " perché abbiamo in mancanza? ", non " loro ".

Il momento migliore per farlo è durante una retrospettiva. Fai capire che la velocità della squadra non è migliorata rispetto agli sprint X e chiedi " come potremmo fare meglio? ". Analizza gli ostacoli che stai affrontando. Suggerisci cose che tu, come Scrum Master, potresti fare per rimuovere alcune di queste e chiedere agli sviluppatori cosa pensano di poter fare da loro.

Se non c'è alcun ostacolo particolare, ma non c'è alcun incentivo particolare, proponi sfide come aggiungere una storia bonus extra a ogni sprint come stimolo o provare a lavorare per deliziare il cliente con piccole caratteristiche inaspettate.

Potrebbe sembrare più facile a dirsi che a farsi, ma non è una questione di rallentamento, senso di colpa, colpa o pressione di gestione. Fai in modo che una squadra agile ispeziona, adatta, migliora, si pone sfide e obiettivi gradualmente più complessi e si diverte e diventa orgoglioso di farlo.

Modifica: Ricorda anche che non sei solo qui. Il Product Owner è il tuo miglior alleato per spingere il team in avanti.

Ricordo che era difficile compiacere l'OP che si aspettava sempre piccole funzioni di "ciliegina sulla torta" o espedienti dell'interfaccia utente durante le dimostrazioni e che la squadra sapesse senza mezzi termini se pensava che avessimo sottoperformato. Alla fine, abbiamo iniziato a pensare automaticamente a cosa avrebbe potuto sorprenderlo, farle piacere e aggiungerlo al prodotto durante lo sprint, in modo che la recensione potesse andare bene. Di conseguenza, la qualità dei prodotti percepiti è aumentata molto come la motivazione del team.

La soddisfazione del cliente è un strong incentivo, soprattutto se l'approvazione avviene durante una riunione pubblica in cui non vuoi apparire poco professionale.

Lo Scrum Master fa parte del team e ha il diritto di chiedere: perché lo hai stimato in questo modo?

Squadre immotivate ma competenti iniziano a scivolare nel tempo. Cercare e discutere indicatori diversi da una velocità artificiale può aiutare a risolvere questo problema.

La copertura del codice sta scivolando? Perché? I test automatici falliscono frequentemente? La costruzione è spesso rotta? Il carico dei difetti viene gestito? Qual è la qualità della documentazione dei difetti? Le funzionalità vengono continuamente consegnate all'interno dell'iterazione? I membri del team continuano a definire obiettivi e suggeriscono miglioramenti durante la retrospettiva?

Se compito e ora stimano le loro storie, può anche essere utile discutere le loro stime di sforzo. Cerca attività spike / di ricerca che trascinano per giorni e chiedi di capire come hanno determinato la necessità e la durata di queste attività.

Infine guarda la variazione di quanto tempo ci vuole per finire storie di dimensioni simili. Le squadre che gestiscono le stime dei punti storia in genere hanno grosse differenze sul tempo necessario per completare una storia. Questa storia di 8 punti che hai pensato avrebbe richiesto 5-10 giorni per essere completata improvvisamente e terminata alla fine dello sprint in 3 giorni? Niente di sbagliato nel chiedere come hanno raggiunto un tale successo e tirato della vittoria dell'ultimo minuto;).

Sono solo un principiante che pratica Scrum. Mi piacerebbe condividere le mie opinioni su questo argomento. Come ho capito, le stime dello sforzo sono l'attività complessiva della squadra che utilizza la pianificazione del poker o della serie di fibonacci o una combinazione di entrambi. Io di solito cerco di far convergere gli sforzi ripetendo la pianificazione del poker ottenendo una breve spiegazione per le citazioni di stima dello sforzo minimo e massimo e infine applicando la Beta-distribuzione (i.e ottimistico + 4 * più-likey + pessimisti divisi per 6). Ciò manterrà la stima dello sforzo non influenzata da uno o pochi individui.

Quindi, quello che suggerisco è far diventare questi 2 ragazzi parte di un altro gruppo di scrum che consente la condivisione della conoscenza e stime di sforzo migliori. L'altro modo è far sì che l'OP o una PMI forniscano anche stime dello sforzo durante la pianificazione dello sprint e convergono gli sforzi discutendo le motivazioni / i motivi delle stime individuali.