Come si fa a far fronte a una squadra che tende a sottovalutare il tempo necessario per completare le attività?

Hai delle retrospettive sugli sprint, giusto? Questo è il momento della domanda: "Come spieghiamo che non abbiamo bruciato molto? Di nuovo?" Potrebbero esserci scuse che non avranno molto senso per te. Prendi nota. Fallo dopo ogni sprint. Arriverà un momento in cui nessuno potrà più discutere con la spiegazione che consideri ovvia.

In qualsiasi sessione di pianificazione potresti chiedere "Cosa c'è di diverso adesso, cosa ci fa credere questa volta che incontreremo questa bassa stima? O non ci crediamo davvero?" A chi pensiamo stavamo scherzando questa volta? " Sarai molto popolare.

Dal lato pratico, altri potrebbero non prevedere le cose che potrebbero o sicuramente avranno a che fare con. Potresti essere in grado di indicare queste cose.

Then we assign these stories to each one of us according to our available capacity

Questo non è molto simile a Scrum. I membri del team in genere scelgono e scelgono i propri problemi dal set selezionato per lo sprint.

Innanzi tutto, questo è il problema della squadra, non quello personale. La squadra esce fuori inaffidabile ogni volta. Quindi, tecnicamente, non è questione di avere a che fare con la squadra, fai parte del team. Se non ti sembra così, forse non ne vale la pena.

La risposta "ufficiale" per lo sviluppo degli argomenti è stimare in "punti" anziché in ore e regolare i progressi attesi in base alla "velocità" o ai punti ottenuti nell'ultimo sprint.

Tuttavia. Non hai davvero bisogno di cambiare molto. Sai quante "ore stimate" hai raggiunto nell'ultimo sprint rispetto al numero effettivo di ore di persona che c'erano.

Quindi sai da quanto sottovaluti. È sufficiente dedicare meno ore di compiti nello sprint per compensare.

L'approccio ai punti è progettato per ridurre l'enfasi sulla stima, che non è mai molto precisa nelle migliori condizioni, e ti consente di raggiungere l'obiettivo di completare ciò che hai inserito nel prossimo sprint. Piuttosto che preoccuparti della durata effettiva di ogni attività.

Vorrei anche raccomandare 1 settimana di sprint per migliorare la stima.

Considererei questo comportamento persistente anche un segno del fatto che il software è troppo difficile da mantenere rispetto agli standard professionali. Il sentimento generale è che le cose dovrebbero andare più veloci.

Oltre a tutte le tecniche procedurali, come discutere le differenze di opinione sui punti di mischia, ci sono alcuni problemi possibili qui:

• I diversi aspetti del problema sono non sufficientemente elaborati in dettaglio ; o peer discussi. Una migliore programmazione tra pari, progetti scritti e simili potrebbero aiutare - se possibile.
• Il sistema software contiene debiti tecnici : è necessario il refactoring. Quando c'è troppa eredità parallela, i dati aziendali e la logica sono intervallati dalla cura dei componenti visivi. Quindi i cambiamenti diventano difficili.
• Il sistema software contiene debiti tecnici : il codice si riferisce al comportamento aziendale non documentato. Si verificano errori di regressione. Quindi il codice aziendale deve essere totalmente integrato con la documentazione sui requisiti aziendali. Tale documentazione deve essere in linguaggio commerciale leggibile e il codice deve fare riferimento alla documentazione e commentare la progettazione del codice.

In generale è difficile riformare un'organizzazione esistente, senza grandi consensi o potere organizzativo.

Ma puoi aggiungere le tue misure, come progetti scritti, comunicazione tra pari e, in particolare, la valutazione del lavoro passato in dettaglio tecnico.

Penso che prima di poter capire cosa fare riguardo alla situazione, devi determinare perché sta accadendo. Il problema è davvero che i programmatori sono terribili nel valutare? (È certamente plausibile. Le stime sono difficili.) O il problema è che le attività sono sottostimate o mal specificate? O ci sono altri problemi come interruzioni costanti o attività non programmate che devono essere risolte immediatamente?

Una volta capito il motivo, puoi pensare a quale sia il problema.

Sembra che parte del problema sia che la tua squadra pensa che i punti e le storie appartengano agli individui. Lo dico perché hai detto:

Then we assign these stories to each one of us according to our available capacity.

e

I would look bad if I have big carryover points too often.

Le storie e i punti appartengono al team, non all'individuo.

In Scrum, tu non hai punti di riporto, il team fa. Inoltre, non dovresti assegnare storie alle persone. Almeno, non dovresti assegnare tutte le storie. Sei tu a decidere su quali storie lavorare per prima, ma scegli solo storie che sei certo possano essere completate. Solo quando questi sono completati dovresti raccogliere la storia successiva nello sprint backlog.

Suggerirei di smettere di pensare in termini di singoli contributori e iniziare a pensare in termini di squadra nel suo insieme. Se una storia è iniziata ma non completata, è colpa dell'intero team . Se un individuo è in pericolo di non finire una storia, il resto della squadra deve intervenire per aiutare.

Essenzialmente, la mischia è molto semplice. Fai uno sprint e calcola quanti punti della storia hai completato . Ecco quanti punti si tira nel prossimo sprint. Non hai bisogno di votare, scegli quel numero o ne scegli di meno. È solo così semplice. Il prossimo sprint, calcolare la media dei precedenti due e regolare di conseguenza. Alla fine la tua squadra si sistemerà su un numero, e tirerai sempre dentro tanti punti.

Questo è esattamente il motivo per cui monitora Hours Velocity .

Ore Velocity è

 estimated hours of completed tasks in sprint   
-----------------------------------------------  
actual hours spent on completed tasks in sprint  

Oh, certo, alcuni aggiungono solo i punti storia completati, ma questa è una metrica diversa. Neanche fa ufficialmente parte della mischia . Fatto in questo modo puoi concentrarti sul confronto tra le stime di sprint e sprint. Altrimenti ti distrai di tempo non dedicato alle attività, che non è costante.

Hours Velocity è una misura di quanto valgono le stime del tuo team. I programmatori sono notoriamente ottimisti. Non è raro che un nuovo team si spenga fino a 1/3, cioè ha bisogno di 3 volte quello che ha stimato. Tracciando e riportando questa metrica, il team impara ad adeguare le sue stime e a migliorarle nel tempo. Ciò porta a un minor numero di funzioni che devono essere eliminate a metà sprint.

BTW, a meno che il tuo mischia master sia anche uno sviluppatore, non dovrebbe votare su stime o punti.

Per quanto riguarda l'assunzione di lavoro, altre persone hanno stimato ... Avvitarlo. Non appena ti viene assegnato un lavoro, vieni con la tua stima. Se è diverso, segnalalo ora. Non piangere se ti allontani senza dire nulla e poi corri fuori dal tempo. Se sarà più lungo di uno sprint, scopri come suddividerlo in un'attività più piccola ora. Avere sempre qualcosa di presentabile fatto alla fine dello sprint.

Raccomando anche scatti di 1 settimana. Ma soprattutto perché garantisce che non si possa perdere molto tempo tra le erbacce.