Clona i biglietti di Jira alla fine di uno sprint - portando avanti lo sforzo e i punti

1

Ho lavorato con Jira all'interno di una metodologia di Scrum Agile per un po 'di tempo. Quello che succede abbastanza spesso è un biglietto stimato e iniziato. Alla fine dello sprint, il 95% del lavoro è fatto. Ciò che di solito accade è che questo ticket viene trascinato fino alla successiva iterazione di rilascio per completare il 5%.

Il mio problema con questo è che questo approccio è:

  • distorce l'immagine di ciò che sta accadendo nello sprint
  • non riflette la quantità di sforzo effettivamente occorsa nell'iterazione
  • sovrastima la quantità di sforzo che viene trasferita
  • demotiva le persone in quanto ciò non riflette lo sforzo richiesto o richiesto.

Una soluzione potrebbe essere quella di clonare il ticket alla fine dello sprint e quindi riassegnare il punto fagotto una stima di:

  • cosa è stato fatto
  • cosa resta da fare

es. dì che hai un biglietto puntato su 8 punti, ed è quasi finito salvo alcune piccole modifiche. Potremmo dire che il ticket è al 90-95%. Quindi, perché non clonare il biglietto e portarlo come 1, riducendo il biglietto precedente di uno e lasciandolo nella versione precedente

    
posta dan 08.08.2018 - 15:56
fonte

2 risposte

9

Se alla fine dei tuoi sprint spesso hai molti ticket importanti che sono fatti al 90% - 95%, allora c'è qualcosa di sbagliato:

Bandiera rossa n. 1: un sacco di cose si riempiono in uno sprint ma non sono finite Bandiera rossa n. 2: hai molti biglietti grandi
Bandiera rossa n. 3: per qualche motivo ciò influisce sull '"ultimo" 10% di progresso

Affrontiamo prima queste cose:
1: Se si hanno ripetutamente dei biglietti rimanenti, si sovrastima la velocità o si sottovalutano i punti storia delle attività. Entrambe le cose possono accadere occasionalmente, ma questa non dovrebbe essere una situazione persistente.

2: Se hai molti biglietti "grandi" che siedono al 95%, significa che hai molti biglietti "grandi", che a loro volta possono essere un segno che non stai abbattendo i compiti abbastanza piccoli.

3: In qualche modo mi sento dubbioso su quelli che mancano del 10% ... o qualcosa sta andando storto in modo persistente alla fine di molte attività (Insufficienti tester per testarli? Non c'è abbastanza hardware?) o quelli sono i compiti in cui hai finito Il 90% del lavoro in 3 giorni e il restante 10% in altri 3 giorni. Verifica che il 90% significhi veramente il 90% e che non vi siano colli di bottiglia.

Ora per la tua domanda:

No, non non clona il ticket e fudge i numeri. Impara dall'esperienza e spezza i biglietti in blocchi più piccoli e migliori. Se una manciata di biglietti di mezza giornata viene trasferita, ciò può accadere (specialmente quando ti rendi conto che hai tempo da perdere prima della fine dello sprint e fai più compiti), ma una manciata di mezze giornate è all'interno il margine di errore per la pianificazione della mischia.

Ricorda che l'attività che DONE non ha - per lo stakeholder - valore zero. Una barca che è a tenuta stagna solo al 90% non funzionerà / fluttuerà (per molto tempo), né una caratteristica che sarà solo del 90% FATTO (cioè implementata e testata, ecc.)

    
risposta data 08.08.2018 - 16:40
fonte
3

L'idea alla base della creazione di una storia che non è stata completata nella sua interezza nella successiva iterazione (o nel backlog) è che la squadra non dovrebbe ottenere credito per il lavoro incompiuto. Questo dovrebbe dare al team un incentivo per finire il lavoro prima della fine dell'iterazione.

Anche il burndown in Scrum funziona in questo modo. Mostra solo i punti bruciati se il valore associato è stato realizzato completando completamente il lavoro. Il 95% fatto significa che il lavoro non è finito e non è pronto per essere consegnato agli stakeholder, quindi perché dovresti essere pagato (bruciando i punti) per questo. E sebbene tu dica che è al 95%, nella mia esperienza quelle ultime percentuali richiedono più tempo del resto, quindi il 95% fatto corrisponde probabilmente a 7 punti (su 8) di lavoro rimanente.

Se portare il lavoro da un'iterazione all'altra è abbastanza comune da iniziare a influenzare la motivazione del team, dovresti affrontare i motivi per cui il lavoro non viene completato all'interno dell'iterazione.
Potrebbe essere che le persone non collaborino abbastanza per finire il lavoro (iniziare una nuova attività è più divertente che fare quella revisione finale per far fare l'altro), o potrebbe essere che le storie siano semplicemente troppo grandi.

    
risposta data 08.08.2018 - 16:36
fonte

Leggi altre domande sui tag