Ho sentito diverse spiegazioni di ciò che Racconto Punti di media e come usarla. Quasi ogni team Scrum li usa, ma non fanno parte della Guida ufficiale Scrum. Questo articolo mira a rimuovere alcuni dei misteri che circondano i punti della storia., Voglio anche condividere le idee sbagliate più comuni che ho incontrato.

Cosa fare Storia Punti di rappresentare?

I punti storia rappresentano lo sforzo necessario per mettere in funzione un PBI (Product Backlog Item). Ogni Punto della Storia rappresenta una normale distribuzione del tempo. Ad esempio, 1 Punto storia potrebbe rappresentare un intervallo di 4-12 ore, 2 Punti storia 10-20 ore e così via., Questa distribuzione temporale è sconosciuta durante la stima. Utilizzando il riferimento PBI relativo a cui stimare, non è necessario sapere quanto tempo ci vuole. Vuoi solo avere un’indicazione approssimativa di quanto tempo il PBI impiegherà per completare.

Quali sono i vantaggi dell’utilizzo dei Punti storia?

I punti storia consentono a una squadra di:

• Stimare rapidamente i problemi. La stima è relativa agli elementi del Product backlog già completati. Questo è più veloce della stima senza alcun riferimento.
• Stima senza dare un impegno di tempo specifico., Quando si stima in ore, si effettua un impegno di tempo preciso. La stima in punti storia impedisce di dare un impegno esatto. Nessuno sa esattamente quante ore stai nominando per un problema specifico.
• Abbracciare l’incertezza che viene fornito con la stima. I punti storia specificano un intervallo di tempo sconosciuto. La selezione da una specifica sequenza di punti storia simile a Fibonacci ci consente di catturare l’incertezza.
• Abbastanza preciso per pianificare sprint in anticipo. Questo ci permette di gestire al meglio le aspettative di tempo degli stakeholder per il lavoro futuro.,

12 Errori comuni commessi quando si usano i Punti storia

1. Equiparando i punti storia a complessità, incertezza o valore

Alcuni PBI possono essere complessi e non richiedono molto tempo. Un PBI comporta l’implementazione di un sofisticato algoritmo. Il team lo ha già fatto prima, quindi sarà in grado di farlo rapidamente. Il contrario può anche essere vero, un semplice PBI che richiede molto tempo. Il team ha bisogno di refactoring un piccolo pezzo di codice, che colpisce un sacco di funzionalità. Di conseguenza, un sacco di funzionalità ha bisogno di regressione testato, che richiederà un sacco di tempo.,

L’incertezza nella stima viene catturata nella sequenza di Fibonacci del punto della storia stessa: 1, 2, 3, 5, 8, 13, 20, 40, 100. La scelta di un numero specifico da questa sequenza riflette la quantità di incertezza. Naturalmente, se l’incertezza è troppo grande per stimare, è possibile utilizzare il ‘?’ carta.

I punti storia non dicono nulla sul valore di un PBI. I punti storia forniscono una stima approssimativa. Potrebbe essere che questo articolo è estremamente prezioso, o non aggiunge alcun valore a tutti. I punti storia aiutano a determinare il ROI di un PBI., È possibile utilizzare i punti storia per tenere conto dello sforzo per fornire tale funzionalità insieme al valore. Ma poiché anche il valore è incerto, non contarti ancora ricco.

I punti storia riguardano lo sforzo. Complessità, incertezza e rischio sono fattori che influenzano lo sforzo, ma ognuno da solo non è sufficiente per determinare lo sforzo.

2. Tradurre i punti storia in ore

Traducendo i punti storia in ore, si smette di beneficiare della velocità di stima relativa. Inizi a lavorare in ore e rischi di dare impegno., Fornisce un falso senso di precisione mentre riduci un punto storia con un intervallo di tempo di 10-20 ore a un numero preciso come 15 ore. Sarà più difficile raggiungere un accordo nelle stime quando si lavora nel regno esatto di ore.

3. Media punti storia

In una sessione di poker di pianificazione, metà della squadra stima un PBI a 3 punti storia e l’altra metà a 5 punti storia. È facile risolvere la discussione semplicemente mettendo 4 Punti della storia come stima. Il team non dovrebbe farlo in quanto tenta ancora una volta di fornire un falso senso di precisione., Il punto non deve essere accurato al 100%. Il punto è essere abbastanza precisi da pianificare in anticipo. Inoltre, potresti perdere una discussione preziosa facendo la media. Forse 5 Punti storia era una stima migliore.

4. Regolazione delle stime dei punti storia dei problemi durante lo Sprint

Quando il team inizia a lavorare su un problema, il team non deve regolare la stima dei punti storia. Anche se si scopre che la loro stima era imprecisa. Se la stima era imprecisa, fa parte della velocità di Sprint finale. È normale che le stime siano a volte disattivate., Non perderai queste informazioni e farà parte della velocità storica di una squadra.

5. Mai bug di puntamento della storia

Un bug non correlato allo Sprint corrente dovrebbe essere solo puntato sulla storia. Il bug rappresenta il lavoro che il team deve completare. Questo non si applica se il team si riserva una percentuale fissa di tempo per lavorare sui bug durante lo sprint. Un bug relativo a un problema nello sprint non dovrebbe essere segnalato come parte della stima originale.

6. Aggiunta di punti storia a piccoli compiti

Un piccolo picco per indagare su qualcosa dovrebbe essere solo time-boxed., È chiaro che ci vorranno 4 ore per farlo, e non è necessario portare alcun punto storia nel mix.

7. Regolazione di ogni sprint del PBI di riferimento

Quando una squadra regola ogni sprint del PBI di riferimento, la velocità di diversi Sprint non è più paragonabile. La squadra perde informazioni non è più possibile utilizzare la velocità storica per pianificare in anticipo. È meglio usare una gamma di PBI recenti come riferimento.

8. Storia che punta di nuovo problemi incompiuti

Quando si sposta un PBI non finito allo sprint successivo, non è necessario rivalutare., La stima potrebbe non essere stata accurata, ma non è un problema. Come risultato della pianificazione Sprint, il team conoscerà tutte le attività necessarie per completare il problema. La stima di questi compiti è in ore. Quindi il prossimo Sprint, il team saprà quanto tempo è ancora necessario per completare il PBI. Il fatto che il PBI non sia stato completato farà parte della velocità.

9. Regolazione della stima del punto della storia perché uno sviluppatore specifico lavorerà su di essa

La storia che punta un PBI è relativa alla storia dell’utente di riferimento e fatta dal team., I membri del team storia puntare il PBI e raggiungere un accordo sulla stima in una sessione di Poker di pianificazione. Un PBI può essere 3 punti storia per uno sviluppatore senior, ma 8 punti storia per uno sviluppatore junior. Il team dovrebbe raggiungere un accordo su quanto lavoro rappresenta per il team e utilizzarlo per la pianificazione. Non dovresti regolare i punti della storia perché una persona specifica farà il lavoro. Forse nel momento in cui iniziano a lavorare sul problema, lo sviluppatore senior sta lavorando su un problema di produzione. Potrebbe quindi essere necessario che lo sviluppatore junior lo raccolga.

10., Non regolare mai il

del PBI di riferimento Quando la composizione del team cambia ,ciò può influire sulle stime della velocità e del punto della storia. Entrambi dipendono dalla squadra che esegue il lavoro. Immagina di aver sottolineato il problema quando erano presenti due sviluppatori senior. Con il tempo che si desidera iniziare a lavorare su questi temi, entrambi hanno lasciato l’azienda. Ora due nuovi sviluppatori junior sono nella squadra. È una buona pratica stabilire una nuova storia utente di riferimento su cui l’intero team ha lavorato., Questo assicura che tutti siano sulla stessa pagina quando la storia punta e dà alla squadra un po ‘ di tempo per stabilire una nuova velocità. Man mano che il team diventa più maturo e migliore nella stima, potrebbe essere una buona idea stabilire nuovi PBI di riferimento.

11. Conforme all’esperto nella stanza.

Quando si pianifica il poker, c’è il rischio che la squadra sia conforme all’ovvio esperto nella stanza. Un modo per risolvere questo problema è quello di lasciare che l’esperto elaborare il lavoro. Quindi chiedi al resto della squadra di stimare senza l’esperto. Costruire competenze specifiche è inevitabile., Non lasciate che questo sottoquotazione il fatto che la stima è uno sforzo di squadra.

12. Non discutere in modo non corretto questioni Story-Pointed in retrospettiva.

Ogni tanto, la storia del team indica un problema in cui è chiaro che la stima era completamente disattivata. È importante discutere di questi problemi e cercare di imparare, quindi le stime future sono più accurate. In uno dei miei team, abbiamo dimenticato di prendere in considerazione la creazione di dati di test durante la stima. Così abbiamo fatto un punto speciale per discutere per ogni problema se la creazione di dati di test era applicabile., Se del caso, vorremmo chiedere se hanno preso in considerazione la creazione di dati di test. Questo ha migliorato molto le nostre stime.

Conclusione

Il concetto di Punti storia è semplice ma difficile da applicare. Quasi ogni team Scrum li usa, ma non fanno parte della Guida ufficiale Scrum. Per questo motivo, le persone hanno opinioni diverse su come dovresti usarli. Il termine Story Point stesso è già confuso, in quanto è possibile utilizzarlo per tipi di lavoro diversi dalle Storie degli utenti. In cima a quello, ‘Punto’ suggerisce un punto Storia rappresenta il valore., Come ha sottolineato un collega, forse il termine “Fattore di pianificazione” contribuirebbe a ridurre la confusione che molte persone sperimentano. Essere consapevoli degli errori che possono essere commessi quando si utilizzano i Punti storia aiuta ad applicarli nel modo giusto.