I punti storia hanno una relazione diretta con le stime delle attività?

A volte è utile per una squadra iniziare così se hanno difficoltà a cogliere l'astrazione. La cosa più importante è se funziona per te. Tuttavia, questa pratica ha anche diverse limitazioni:

• Diversi membri del team impiegheranno tempi diversi per la stessa storia. 10 punti per il nuovo noleggio dovrebbero essere equivalenti a 10 punti per la rockstar, in modo da poter riallocare dinamicamente le storie secondo necessità.
• Le parti interessate saranno tentate di basarsi direttamente su tali stime anziché su Velocity.
• I membri del team saranno tentati di manipolare queste stime anziché pensarci astrattamente e lasciare che la velocità evolva in modo naturale.
• È difficile considerare fattori come interruzioni, disponibilità ecc.
• La risoluzione è corretta. È probabile che le storie più piccole di un giorno vengano sopravvalutate.
• Un sacco di storie che comportano il debug sono difficili da stimare in termini di tempo, ma è più facile da stimare come una relativa complessità.
• Infastidisci i puristi più agili (non importa, mettilo nella colonna "più").

Sì, va bene. I punti storia sono unità astratte. Possono essere correlati o derivati da unità reali, ma non è importante quali unità, purché tutte le storie usino le stesse unità. Poiché il numero di unità di lavoro consentite in un'iterazione è basato sul numero di unità di lavoro completate in passato, le unità devono essere coerenti.

Ecco un esempio: supponiamo che tendiamo a sovrastimare, in media, impiegando metà del tempo per svolgere un'attività come stimata. Nell'ultima iterazione della settimana abbiamo stimato 10 giorni di lavoro, ma ci sono voluti cinque giorni effettivi per eseguirli. Poiché le prestazioni passate sono 10 giorni stimati, consentiamo 10 giorni stimati nella successiva iterazione. Finché le nostre stime sono costantemente negative, tutto funziona. Ecco perché le unità reali non contano.

Sì, in realtà è una pratica comunemente usata, anche se alcune persone direbbero che stai stimando in Ideal Developer Days, o semplicemente Ideal Days. Non rimanere impiccato a usare il termine story point. Questo metodo è in realtà menzionato nel libro Agile Estimating and Planning di Mike Cohn. Vedi il capitolo 5. Stima in giorni ideali.