2009-02-12 9 views
7

Diciamo che il prodotto X vale 10 punti. Lo sviluppo inizia nello sprint Y, ma non è completato nel tempo. Cosa ne pensi dei punti della storia quando calcoli la velocità di Sprint Y?Mischia: prodotti non finiti e velocità di sprint

si farebbe:

a. Assegna 0 punti storia per lo sprint Y e 10 punti per lo sprint alla fine completato;

b. Determina i punti storia per il lavoro rimanente (diciamo 3) e assegna la differenza allo sprint Y (7 nel nostro esempio); oppure

c. Qualcos'altro?

Grazie in anticipo!

+1

Questa domanda è fuori tema perché non è all'interno lo scopo di questo sito, come definito in [Quali argomenti posso chiedere qui?] (// stackoverflow.com/help/on-topic) Vedi anche: [Quali tipi di domande dovrei evitare di chiedere?] (// StackOverflow .com/help/dont-ask) Potrebbe essere possibile chiedere su [un altro sito Stack Exchange] (// stackexchange.com/sites#name), ad esempio [pm.se] o [softwareengineering.se]. per leggere la pagina dell'argomento nel centro assistenza per qualsiasi sito su cui intendi pubblicare una domanda: – Makyen

risposta

6

Dipende se ti interessa la tua velocità "istantanea" o "media". Personalmente, non lo renderei più complicato del necessario e basta aggiungerlo nello sprint in cui è stato completato. Calcola la tua velocità media osservando il numero medio di punti completati per sprint negli ultimi 3, 6 e 12 mesi. Speriamo che alla fine convergeranno e avrai una buona idea di quanto puoi fare in uno sprint.

+0

Grazie per quello. Abbiamo constatato che la velocità dallo sprint allo sprint avrebbe visto-visto, dato che lo sprint x avrebbe avuto un bassa velocità a causa di articoli incompleti e sprint x + 1 avrebbe una velocità artificialmente alta dovuta agli oggetti che si sono rotolati. Una media mobile su diversi sprint lo ha spianato. –

4

Assegnare 0 punti per lo sprint Y e 10 punti quando la storia viene completata. O la storia è fatta o non è fatta. Non c'è via di mezzo. Vuoi evitare il 50% o i tuoi team potrebbero implementare molte storie a metà strada e nessuna completamente.

È perfettamente ok non finire una storia durante uno sprint e completarla nel prossimo sprint. Ma non dovresti presentare questa storia al proprietario del prodotto durante la revisione sprint.

Se hai abbastanza storie per un determinato sprint, non importa se la storia è completata con questo sprint o il prossimo. Le cose andranno in media.

È anche importante spiegare al team e agli stakeholder che la velocità aiuta a stimare quando il rilascio avverrà e non è una misura delle prestazioni del team.

La squadra deve essere giudicata sul risultato finale che producono, non quando questi risultati sono prodotti.

Combinato con un backlog ben priorizzato, creerete software di buona qualità che significa che i vostri clienti hanno bisogno.

2

Questa è una delle idee dello sprint, la "completezza" è binario, sia fatto o non, nel corso del tempo la squadra (s) avrà migliore preventivo e questa domanda perderà rilevanza

1

MA ...

La prossima domanda è come caculate il vostro impegno per lo sprint dopo Y. Se il tempo passato mostra che avete una velocità media di 20 punti. Se porti avanti la storia, porti oltre 10 punti. Tuttavia, se pensi che siano rimasti solo 3 punti:

A) Prendi un altro 17pt per riempire la tua capacità stimata di 20 punti B) Prendi solo 10 punti in più mentre la storia riportata era originariamente stimata in 10 punti

Abbiamo avuto un casino cercando di fare A. Cosa pensano gli altri?

[Update]

ho postato una domanda su questo:

Work out sprint capacity when carrying over story points in scrum

0

La situazione qui non è soddisfacente, ma al momento stimiamo il lavoro rimanente per le storie incompiute. Se è solo intorno al 20% o meno, lasciamo la storia e i punti nello sprint che sono. Se più di questo chiediamo al PO se dovessimo finire la storia, se sì, allora passiamo al nuovo sprint. Tuttavia questo non è soddisfacente per diverse ragioni. Le prime storie grandi o rischiose avrebbero dovuto essere iniziate all'inizio dello sprint, in modo da evitare il non completamento. In secondo luogo otteniamo stime di velocità imprecise (ma probabilmente più agevoli) che sono meno utili andando avanti In terzo luogo non è severo, e il team è come un bambino di 2 anni, mostra una leggera debolezza e vuole sfruttarlo.

Infine, la rigidità viene rafforzata con il passare del tempo, i team stanno trovando i loro piedi in una certa misura e stanno imparando i modi migliori di trattare con le cose. Abbiamo già enormi variazioni di velocità - la maggior parte delle squadre ha un commento su ogni sprint su quali fattori (vacanza, malattia, ecc.) Hanno influenzato ogni sprint ... totalmente negativo :(

+0

Non penso che questo cerchi di rispondere alla domanda dell'OP. Non sono nemmeno sicuro di cosa sto guardando per essere onesto, ma non sembra una risposta a qualcosa. –

Problemi correlati