Quali problemi sta risolvendo SP Estimating e come ti sta beneficiando?
Nel nostro progetto attuale siamo 6 sviluppatori e facciamo stime basate sul tempo assoluto, cioè 2 SP corrispondono a un giorno e la durata dello Sprint è di 4 settimane (20 giorni lavorativi). Quindi pianifichiamo circa 200 SP (secondo il calcolo 240 = 2*20*6) con 40 SP di buffer. Ma stiamo notando dagli ultimi due Sprint che riusciamo a completare circa 160 SP e ora il Product Owner vuole sapere il motivo della diminuzione della produzione negli ultimi Sprint, dato che è chiaro che anche con il buffer dovremmo essere in grado di raggiungere un minimo o circa 200 SP. Come posso gestirlo?
In secondo luogo, sto pianificando di passare a una stima basata su valori relativi utilizzando la serie di Fibonacci. Ma la mia domanda sarebbe come prendere una Storia di riferimento, cioè la mia storia utente da 1 o 2 SP per la stima relativa? Credo che anche qui la storia utente di riferimento dovrà essere stimata utilizzando il tempo, cioè diciamo che per questa storia utente ci servono 2 giorni e da lì stimare le altre in modo relativo.
Infine, abbiamo la seguente struttura per la formulazione dei ticket:
Storia utente, cioè ticket di funzionalità
- Sotto-attività 1
- Sotto-attività 2
Attualmente, con la stima del tempo assoluto, stimiamo le sotto-attività e sommiamo gli SP e aggiorniamo il ticket principale della storia utente con la somma. È una buona opzione o ci sono modi migliori e, inoltre, se passo alla stima relativa, come dovrei effettuare la stima per la struttura del ticket sopra descritta? Recensione raccolta e ospitata su G2.com.