Normalizzare i punti storia tra i team, c'è un grosso problema?

Ho provato questo approccio con diversi team e non porta a un'efficienza cross-team. Abbiamo sempre utilizzato una storia di riferimento, che tutti hanno compreso, come base e con un valore diverso da 1 (2 nel nostro caso) per assicurarci che per le cose che sapevamo fossero ancora più piccole di quella storia di riferimento potremmo dare a 1.

Il concetto cade a pezzi non appena la squadra viene portata nella stanza delle stime e ha bisogno di dire che cosa è più GRANDE della storia di riferimento. Alcuni team, per qualche ragione, vedono qualcosa come 4 volte la storia di riferimento, altri stimano 2 volte la storia di riferimento. Sono entrambi corretti, perché I PUNTI DELLA STORIA NON SONO ORE .

Se il team è coerente nelle sue dimensioni , le stime del team sono valide e puoi prevedere dalla velocità che il team raggiunge. Ma il confronto tra le squadre non funziona. La squadra A, che utilizza regolarmente incrementi maggiori di riferimento, sembrerà sempre realizzare più punti storia in uno sprint. La squadra B verrà valutata come "a basso rendimento", quando in realtà si stima solo su una scala diversa.

Questo mi è stato reso ancora più chiaro quando ho preso circa 3 settimane di ferie, permettendo di fare due giri di stima in mia assenza con un team leader che gestiva altre squadre con stime "più alte". Quando sono tornato, la nostra velocità era improvvisamente aumentata drasticamente e tutti i punti della storia per la squadra erano molto più alti, ma non avevamo effettivamente realizzato altro lavoro.

(Questo ha anche evidenziato che ho avuto un'influenza non uniforme sulle dimensioni delle stime fatte dal team)

In conclusione, usare una storia di riferimento è molto utile. L'organizzazione può comprendere il processo di stima e sentirsi come tutti standardizzanti . Tuttavia, oltre a questo, non mi fiderei di alcun allineamento delle dimensioni delle stime tra i team, a meno che tu non abbia le stesse persone che fanno tutte le stime e rimuovi il team dall'equazione .

Questa è una cattiva idea. L'intero punto di stima per punti della storia è di avere un'unità astratta che non è direttamente confrontabile con il tempo o attraverso i team. Non impari alcuna informazione utile cercando di avere punti storia con dimensioni uguali tra le squadre. Hai bisogno di una velocità ragionevolmente accurata e di punti totali per fare un confronto reale, se la squadra A stima un progetto a 200 punti non significa necessariamente che è più piccola della squadra B stimando una storia di 400 punti, hai bisogno anche di velocità per ottenere un significato confronto. È possibile che i suoi 4 sprint di lavoro per la squadra A e 5 per la squadra B. Più si cerca di avere cose simili e più confronti avverranno, anche in modo informale alcune persone inizieranno a fare questi confronti. Ci sarà sempre una leggera pressione per non essere la squadra di velocità più bassa in qualsiasi ambiente multiplo, tentando di mantenere coerenti i punti storia tra i team questo renderà questa pressione più pronunciata.

La prima cosa che mi chiedo è: cosa speri di ottenere facendo questo?

Stai cercando di capire la dimensione relativa dei progetti? Beh, non vedo che questo aiuti molto (oltre a darti un'ipotesi approssimativa sul fatto che qualcosa sia più grande o più piccolo). I punti storia sono, per loro natura, applicabili solo alle persone che li hanno valutati.

Il tempo della storia per aiutarti a illustrarlo. Un progetto su cui ho lavorato era un sito web che era per lo più pagine CRUD ma aveva un'interfaccia super complicata. Si supponeva che questo progetto fosse una sostituzione di una vecchia app per mainframe e volevano che la loro pagina principale simulasse il vecchio sistema in termini di capacità di gestire un rapido input da tastiera. E questa pagina conteneva tonnellate di parti mobili in cui la modifica di un input poteva abilitare o disabilitare tonnellate di altri campi, modificare i requisiti di convalida, nascondere o mostrare parti della pagina, si ottiene l'idea.

Abbiamo avuto uno sviluppatore junior che ha fatto principalmente frontend e me per gestire l'interfaccia utente. Lo sviluppatore junior poteva gestire HTML, CSS e alcuni jQuery di base. Se avesse stimato lo sforzo che le avrebbe portato, sarebbe stato di oltre 100 piani.

Ero uno sviluppatore senior a questo punto e ho suggerito di utilizzare Angular per quella pagina. E ho stimato il lavoro con un totale di 30 punti. Anche se c'è stata una curva di apprendimento per i nostri sviluppatori junior, abbiamo ottenuto un'interfaccia utente migliore con meno sforzi rispetto a quelli che avremmo altrimenti.

Il punto centrale di questa storia è che lo sforzo dipende molto dalle persone che fanno il lavoro. Un team esperto può elaborare progetti migliori, lavorare più velocemente o avere meno problemi. Alcuni di questi vengono inghiottiti in velocità di squadra, altri no.

Torna a ciò che stai cercando di ottenere. Stai cercando di confrontare come funzionano i team e quanto sono bravi? Perché sono abbastanza sicuro che lo otterrai se lo vuoi o no.

Quando i punti della storia sono relativi a una squadra, l'unica cosa che puoi legittimamente confrontare con una squadra è se stessa. È possibile tenere traccia degli aumenti di velocità, della stima più accurata, ecc. Per un determinato team. Ma non si può dire "la squadra A ottiene 50 punti in uno sprint di 2 settimane e la squadra B ne fa solo 30. Perché la squadra B sta rallentando così tanto?". Qualsiasi tentativo in questo modo può essere arrestato istantaneamente ricordando che 1 punto A della squadra = = = 1 punto B della squadra (più un intero gruppo di altri argomenti). Ma non appena hai un modo per dire che 1 punto è 1 punto tra i team, ora i confronti diretti sono inevitabili. Se le persone vogliono consapevolmente fare quei confronti o no, succederanno. E posso promettere che qualche manager farà lo stesso e lo userà per dichiarare che una squadra sta "eseguendo".

Potrei mancare qualcosa qui, ma tutto quello che posso vedere è che questo finirà con poco beneficio e molti potenziali svantaggi. In breve, non farlo.