Come misurare i punti di stima e storia in Scrum? [chiuso]

Question

Facciamo un esempio supponiamo che abbiamo 5 storie A, B e C, D, E.

Importance Name Estimate
90         B 
70         A 
50         C 
35         E
10         D 

Le storie sono ordinate in base alla loro importanza (priorità). Come li stimate? È stimato in base alla dimensione della funzione? Ad esempio, ho dato loro dei valori di stima:

Importance Name Estimate
90         B     10
70         A     12 
50         C     9
35         E     20  
10         D     11

Supponiamo che sia uno sprint di 2 settimane. Si tratta di una dimensione temporale di 14 giorni = 5,14x5 = 70 giorni-uomo. Cosa significa il valore 10? Significa quantità di tempo (ore o giorni) che una squadra dovrebbe trascorrere? E quali sono i punti della storia? Supponiamo che questo sia il primo sprint; come stimerai il numero di sprint quando non hai la velocità dell'ultimo sprint?

Answer 1

Argh! Mi serve bene per scrivere dalla memoria.

Un punto della storia è ovviamente correlato alla stima e quando provi a capire quanto puoi fare per uno sprint, un punto della storia è un'unità di "lavoro". necessario per implementare una parte o un'intera funzionalità. Un punto della storia potrebbe essere un giorno, un'ora o qualcosa nel mezzo. Ho confuso il "preventivo" e "punto di storia" sotto, non so cosa stavo pensando.

Quello che ho scritto in origine era "preventivi" e "punti trama". Quello che intendevo scrivere (e modificato di seguito) era "punti trama" e "velocità".

---

I punti della storia e la velocità vanno di pari passo e lavorano insieme per provare a darti un senso di "quanto possiamo completare in un determinato periodo di tempo".

Facciamo un esempio.

Supponiamo che tu voglia stimare le funzioni in ore, quindi una funzione che ha una stima di 4 richiederà 4 ore per essere completata, da una persona, quindi assegni tale stima a tutte le funzioni. Considera quindi quella caratteristica, o la sua "storia", vale 4 punti quando si tratta di competere per le risorse.

Ora diciamo anche che hai 4 persone nel tuo progetto, ognuna delle quali lavora una normale settimana di 40 ore, ma, a causa di altre cose che accadono intorno a loro, come supporto, parlare con il marketing, riunioni, ecc. essere in grado di lavorare al 75% sulle funzionalità effettive, l'altro 25% verrà utilizzato su tali altre attività.

Quindi ogni persona ha 30 ore disponibili ogni settimana, il che ti dà 30 * 4 = 120 ore totali per quella settimana quando conti tutte e 4 le persone.

Ora diciamo anche che stai cercando di creare uno sprint di 3 settimane, il che significa che hai 3 * 120 ore di lavoro che puoi completare. Questa è la tua velocità, la velocità con cui ti muovi, quanti "punti storia" puoi completare.

L'unità della tua velocità deve essere compatibile con l'unità per i tuoi punti trama. Non puoi misurare le storie in "quante tazze consumeranno gli sviluppatori durante l'implementazione di questo" con " quante ore abbiamo disponibile " ;.

Quindi si tenta di trovare una serie di funzioni che insieme raggiungono, ma non oltre, 120 punti, classificati in base alla loro priorità. Ciò significherebbe semplicemente sommare l'accumulo dall'alto e verso il basso fino a quando non si raggiunge un'attività che ribalta la somma o equivale a quei 120 punti. Se è capovolto, non includere l'attività.

Potresti facilmente stimare in giorni o tazze di caffè consumate dallo sviluppatore, così come il numero è rappresentativo del tipo di lavoro che stai svolgendo e può essere correlato al lavoro effettivo che eseguirai ( cioè, quanto tempo hai a disposizione).

Dovresti anche valutare il tuo carico di lavoro dopo ogni sprint per capire se quel numero del 75% è accurato. Ad esempio, se hai gestito solo metà di ciò che hai deciso di fare, capire se le stime delle funzionalità erano errate o se le stime del carico di lavoro erano errate. Quindi prendi in considerazione ciò che hai imparato durante la stima e la pianificazione dei seguenti sprint.

Nota anche che le funzioni dovrebbero essere divise se diventano troppo grandi. Il motivo principale di ciò è che stime più grandi hanno molte più incertezze incorporate in esse, e puoi mitigarle suddividendole in sotto-caratteristiche e stimandole. La grande caratteristica generale diventa quindi la somma di tutte le funzioni secondarie. Potrebbe anche darti la possibilità di dividere la funzionalità su più persone, assegnando funzioni secondarie diverse a persone diverse.

Una buona regola empirica è che le funzioni che hanno una stima superiore a 1 giorni dovrebbero probabilmente essere divise. *

Answer 2

Ricorda che i punti sono solo ROM (ordine di grandezza approssimativo) stabilite mediante l'uso di " Planning Poker " come una pratica comune. I primi Sprint sono quando inizi a identificare cosa significano i punti per la squadra e più vai avanti più la squadra ottiene con precisione.

Inoltre cerca di usare punti leggermente più distanziati. Una pratica che ho visto e usato è quella di utilizzare la sequenza fibonacci , assicurandoti di don non ci sono troppe differenze di 1 punto.

Inoltre, non dimenticare i tester, quando si indica una storia in cui chiunque faccia test deve ponderare poiché a volte una semplice attività di sviluppo può causare un grande sforzo di test e se sono veri Sprint l'idea è di avere tutto completato come potrebbe essere spedito (costruito, testato e documentato). Quindi la stima di una storia è determinata dal team e non da un individuo.

Answer 3

Il valore 10 è semplicemente un valore relativo alle altre stime, ad es. è la metà di un 20 o leggermente più difficile di un 9. Non c'è una traduzione specifica di 1 punto = x ore di sforzo è qualcosa da sottolineare.

Dove lavoro, abbiamo ciò che chiamiamo "punti epici" che è quanto sia difficile una storia di alto livello, ad es. integrare la ricerca in un nuovo sito Web, che sarà composto da più storie da completare e quindi stimeremo le ore su ciascuna storia creata dalla scomposizione di ogni epopea, ad es. basta inserire Cerca i documenti di supporto sul sito. I "punti epici" sono distribuiti in una variazione dei numeri di Fibonacci (1,2,3,5,8,13,21,28,35) in modo che epici più ampi e più vaghi ottengano semplicemente un valore elevato, ad es. qualcosa di più grande di 8 indica che può essere scomposto in storie più facilmente stimabili. Vale anche la pena notare qui che dove lavoro lavoriamo solo 5 giorni alla settimana e all'interno di ogni sprint un giorno viene perso per riunioni come la demo, la riunione di pianificazione dell'iterazione, la retrospettiva e la revisione, quindi mancano solo 9 giorni allo sprint. Aggiungendo la programmazione in coppia per alcune cose, tempo per correggere bug e altri lavori non di progetto come i ticket di supporto e diventa piuttosto difficile dire quante ore saranno trascorse dal pugno di sviluppatori nello sprint.

I primi sprint sono quelli in cui i valori iniziano a diventare più concreti in base all'esperienza acquisita, le stime possono diventare più chiare in termini di come indovinare il valore.

Answer 4

Con un nuovo team o progetto partiamo sempre dal presupposto che un punto della storia sia un singolo "giorno ideale", e immaginiamo che ogni sviluppatore ottenga circa 3,5 giorni ideali alla settimana, ed è così che calcoliamo la nostra probabile velocità iniziale.

Dopo aver attraversato la "pianificazione poker" " palcoscenico ed equilibrato / rispetto di tutte le tue storie, la durata reale di un punto della storia è davvero sconosciuta - tutto ciò che hai davvero è una buona idea della durata relativa e usa il tuo miglior giudizio per venire con una probabile velocità.

Almeno, è così che faccio!

Se stai anche puntando i punti della tua storia ad essere approssimativamente uguale a un giorno ideale, allora suggerirei di dividere le tue storie in storie più piccole, altrimenti non ti divertirai a pianificare e tenere traccia delle iterazioni.

Answer 5

Buone risposte dappertutto.

Un punto che vorrei aggiungere è che non è molto importante ciò che scegli come base per il valore dei tuoi punti (ore, giorni ideali, qualsiasi altra cosa). L'importante è mantenerlo coerente.

Se lo mantieni coerente, ti permetterà di scoprire "velocità reale" della tua squadra. Ad esempio, supponiamo che tu abbia avuto poche iterazioni:

iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points

E ora stai iniziando l'iterazione 4 e hai il seguente nel backlog (ordinato per priorità):

item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points

Ora supponendo che le tue stime dei punti siano coerenti, puoi essere ragionevolmente sicuro che la squadra finirà gli articoli 1,2 e probabilmente 3 ma sicuramente non 4.

È possibile applicare lo stesso per rilasciare il backlog per migliorare la previsione della data di rilascio. Questo è ciò che consente ai team Scrum di migliorare le proprie stime man mano che procedono.

Answer 6

JB King ha la risposta migliore, ma nessun voto significa che si stanno diffondendo informazioni errate e contribuendo all'interpretazione generalmente scadente della mischia. Consulta le risposte reali di una delle persone che hanno progettato Scrum qui:

http: //blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight

Ricorda, si tratta di sforzo, non di complessità.

Ora leggi e guarda un video qui:

http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points