Come prevenire una sovrastima intenzionale nelle storie degli utenti?

Il punto chiave di Velocity e la stima della storia dell'utente devono servire come misura relativa di ciò che gli sviluppatori possono finire durante lo sprint. Velocity non deve essere utilizzato per il confronto con altri team. Quindi, se gli sviluppatori sovrastimeranno le storie degli utenti, la velocità aumenterà e saranno forzati a fare entrambi più lavoro prossimo sprint o sovrastima di nuovo.

Questo è ciò di cui gli sviluppatori agili dovrebbero essere consapevoli. Se hai sviluppatori che vanno consapevolmente contro questo sistema, allora hai persone che vanno consapevolmente contro lo sviluppo agile e quelle persone dovrebbero essere gestite in modo appropriato.

Inoltre, il proprietario del prodotto fa parte del team di sviluppo. Non è qualcuno da fuori. Fa parte del team e dovrebbe essere presente durante tutte le riunioni importanti del team.

What is there to stop the development team from over-estimating intentionally the time it takes to complete user stories?

Direi orgoglio e senso di professionalità. Assumi professionisti veri e non devi preoccuparti di questo. Se hai persone che stanno intenzionalmente cercando di sovvertire i tuoi sforzi di sviluppo, hai problemi più grandi dei semplici problemi di stima.

La storia della stima del software è una storia di sottostima , non di sovrastima. Secondo la mia esperienza, anche quando gli sviluppatori pensano di stare gonfiando le loro stime, di solito sono ancora eccessivamente ottimisti . I progetti con stime inferiori alla metà della realtà non sono infrequenti.

La sottovalutazione è anche significativamente più a rischio che a sopravvalutazione, a causa di ciò che accade al progetto lungo la strada. I progetti sottovalutati richiederanno probabilmente più tempo di quanto lo stesso progetto sia sovrastimato a causa dell'aumento esponenziale delle "attività di recupero", come correzioni di errori a causa di angoli tagliati, riunioni di stato costante, ripianificazione e salvataggio. Le pietre miliari hanno anche effetti a valle, che influenzano i tempi di altri team e clienti. Distruggono volontariamente la fiducia dei partner nella capacità del team di consegnare.

In sostanza, ogni volta che una squadra è preoccupata per la sovrastima, vorrei sottolineare che il rischio molto più grande è la sottovalutazione. Per una buona recensione di questo e di altri argomenti relativi alla stima, adoro il libro Stima del software: Demistificare l'arte nera .

Un principio essenziale di sviluppo agile è la totale apertura. Quindi, in teoria, almeno, non c'è nulla che impedisca al team di scrum di derubarvi, a parte il fatto che sarebbe immediatamente ovvio. Questo, e il fatto che il team avrà iniziato promettendo questa apertura e che le persone sono fondamentalmente oneste.

Quindi (sto chiedendo questo in modo puramente ipotetico): cosa deve impedire a tu di rubare al negozio di dolci locali?

Un po 'meno frettolosamente: le stime della squadra saranno controllate contro la realtà alla fine dello sprint. Stanno alla lavagna ogni giorno per dire cosa si aspettano di lavorare, e il giorno dopo rispondono dei loro progressi contro questo impegno. Cosa si può volere di più?