Qual è il modo migliore per stimare i punti storia nella mischia?

Non penso che sia un grosso problema.

Ci sono due cose ovvie che potrebbero causare questo. Uno è che stai vivendo una leggera deflazione dei punti. L'altro è che il tuo team sta diventando più veloce. (Spero sia quest'ultimo!)

In ogni caso, non dovrebbe essere un grosso problema. I due principali usi di velocity sono capire quanto lavoro intraprendere nella prossima iterazione e fare stime approssimative delle date di consegna per pezzi più grandi di lavoro. Nessuno di questi è danneggiato da una velocità che cambia gradualmente. Infatti, se la velocità migliorata deriva dal migliorare, i tuoi nuovi numeri presentano un'immagine più fedele della capacità della squadra.

Se la velocità sta cambiando troppo rapidamente per il comfort, allora una risposta è storie canoniche. Passa attraverso gli ultimi due mesi, individuando 3 storie ciascuna per rappresentare i livelli dei punti che usi. Mettili sul muro dove fai le stime. Quindi, come stimati, usali come confronto con la storia con cui hai a che fare. Ciò dovrebbe ridurre sia la deriva che la volatilità nelle stime.

Fondamentalmente, questo non è davvero un grosso problema, dato che la maggior parte di queste cose verrà fuori nel lavaggio. In generale, la manipolazione esplicita dell'output delle stime sarà negativa per il processo. La stima dei punti storia funziona al meglio quando le squadre tengono gli occhi sulla palla - stai valutando la relativa complessità delle storie rispetto ad altre storie, e fintanto che hai informazioni storiche a portata di mano per le storie completate, probabilmente vedrai le cose sistemarsi a lungo termine. Questo è un luogo in cui la coesione del team paga i benefici, in quanto un team finirà per sistemarsi su metodi e storie di riferimento per la stima della storia.

La deflazione del punto di storia può essere un problema lieve, tuttavia, poiché il range di stime dei punti viene compresso, si iniziano a perdere informazioni sulla regolazione fine della velocità e tale compressione può avere effetti negativi nella stima della lunghezza per la consegna di pianificazione a lungo termine della release (in quanto moltiplicherete gli errori introdotti dalla compressione di tutte le vostre storie in un intervallo ristretto). In generale, si desidera che i risultati dell'aumento della velocità, dovuti all'esperienza da esprimere, assumano più punti della trama piuttosto che delle stime che scendono. Il modo di combattere è quello di fare continuamente riferimento alle stime completate in precedenza e assicurarsi di valutare sempre la complessità. Non dire mai per quanto tempo pensi che qualcosa stia per prendere, basta confrontare la difficoltà complessiva di una storia rispetto alle storie precedenti. Supponiamo che tu abbia un'app che supporta piattaforme mobili e che devi effettuare il porting su un'altra. È simile a un porto precedente? Più difficile, perché la piattaforma ha strumenti peggiori? Più facile, perché hai un debugger migliore? Questo dovrebbe informare le tue stime, non il fatto che questa porta probabilmente andrà più veloce perché i tuoi team stanno ottenendo buone stime. Concentrarsi sulla complessità dovrebbe aiutare a risolvere questo problema, nella misura in cui ce n'è uno.