Scrum - come riportare una User story parzialmente completa al prossimo Sprint senza inclinare l'arretrato

Sono sorpreso che non ci sia una risposta diretta a questo. Mi aspettavo un coro di "opzione D, manichino"!

Dato che non sembra mancare nulla di ovvio, abbiamo pensato che questa è una delle decisioni che ogni team deve prendere autonomamente in base a come vogliono lavorare e quali sono le metriche più importanti per loro.

Abbiamo deciso di mantenere una registrazione accurata delle storie degli utenti che abbiamo implementato è essenziale, in quanto costituiscono la base per i nostri test, la documentazione di supporto e le note di rilascio, che escludono l'opzione B.

Successivamente abbiamo capito che essere in grado di eseguire con precisione la programmazione dello sprint era essenziale, che esclude l'opzione C.

Abbiamo quindi concluso che l'opzione A è giusta per noi. Stimeremo a rivalutare i punti storia per le storie che completiamo parzialmente in uno sprint, in modo da poterle pianificare correttamente negli sprint successivi. Col passare del tempo, il portafoglio prodotti segnalerà leggermente la quantità di punti storia che abbiamo implementato, ma questo sarà meno problematico rispetto a qualsiasi altra opzione e potrebbe essere risolto cambiando la nostra tenuta dei registri e la nostra segnalazione.

L'opzione A è una linea d'azione comunemente raccomandata. Non si assegnano punti per il completamento della storia per lo sprint precedente e per riportare la storia nel backlog del prodotto, in cui è rinominata. Calcoli la tua velocità (e altre metriche) in base agli user story completati e al valore aggiunto. Quando inizi a pianificare il prossimo sprint, prendi le storie con la priorità più alta in base al loro valore (che potrebbe o meno includere la storia incompiuta, se le priorità del business sono cambiate). Quando valuti la storia, includi il lavoro che è già stato fatto quando si calcola la nuova quantità di punti per la storia.

Ovviamente, un'opzione alternativa (e la mia preferenza) sarebbe quella di usare il numero stimato di punti storia, che è qualcosa che ho fatto in passato. Questo fa presupporre che la tua stima fosse buona e ben fondata, ma hai buttato giù troppo lavoro per lo sprint (es. La storia valeva davvero 3 punti, ma il problema sta nel fatto che hai tirato giù 15 punti storia quando avresti dovuto solo abbattere 13). È un'ipotesi potenzialmente pericolosa se non sei sicuro della tua capacità di eseguire le stime, ma potrebbe funzionare in base al team e al processo.

Tuttavia, lei dice che ciò "rovinerà la segnalazione del Product Backlog". Il Product Backlog dovrebbe essere comunque dinamico, con l'ordine e le stime di ogni storia che cambiano man mano che si comprende la tecnologia, il sistema, i requisiti e il cliente. In genere, ciò che viene segnalato dal Product Backlog è il numero di user story e il numero totale di story point. Ci si dovrebbe aspettare che queste modifiche cambino man mano che le priorità cambiano, vengono aggiunti nuovi requisiti, vengono rimossi i requisiti non validi e vengono fornite ulteriori informazioni.

Nel mio attuale team facciamo c).

La velocità dovrebbe spiegare le cose che la squadra ha davvero concluso nello sprint. Qualcosa che non è stato consegnato non ha valore per il cliente, quindi non contiamo punti per questo, è tutto o niente.

Quindi spostiamo l'intera storia non finita al prossimo sprint e tutti i suoi punti storia saranno aggiunti alla velocità del prossimo sprint. Le velocità si livellano nel tempo e prendiamo una media dei pochi sprint precedenti come riferimento per determinare le velocità future di stima.

Pensare troppo a questo aspetto sembra più complicato di così ... In realtà è piuttosto semplice:

Opzione C

Le storie incomplete tornano nel backlog del prodotto, senza che i punti vengano modificati. Quando si pianifica il prossimo sprint e cosa si può fare, la discussione dovrebbe includere il fatto che gran parte del lavoro è già stato realizzato. Se la squadra decide di inserirla nello sprint, allora entra in gioco, con il suo numero originale di punti. In caso contrario, rimane nel backlog. Fatto. I punti vengono assegnati allo sprint in cui è stata completata la storia.

Se aiuta, puoi tracciare una metrica separata di "lavoro residuo" per ogni story utente, in modo che se, alla fine dello sprint, la trama non è completa, il lavoro stimato rimanente può essere annotato nella storia e preso in considerazione quando si pianifica la sua inclusione in uno sprint successivo. Ma anche in questo caso, non modificare il valore in punti della storia originale.

Se il tuo strumento per i rapporti non è in grado di gestire l'opzione A con precisione, sceglierei l'opzione B a meno che tu non abbia alcuna speranza di utilizzare mai le tue metriche.

In alcuni casi è possibile fare l'opzione B AND non inclinare cosa significa chiudere restringendo l'ambito della vecchia attività che si sta per chiudere e solo creando una nuova attività per l'ambito che rimane. Ciò rende la storia più sensata semanticamente e di solito indica i luoghi in cui dovresti considerare di rompere ulteriormente il compito. A volte questo non è possibile o logico e hai semplicemente un'attività di tale portata o che si trova in quel livello di problemi.

modifica Ciò presuppone (come ritengo che il PO stesse ipotizzando) che il lavoro quasi completo non sia stato abbattuto in via prioritaria e che il raggiungimento del payoff dello sforzo precedente lo mantenga sufficientemente alto nell'elenco per continuare a funzionare. So che alcuni negozi non lo fanno, ma la maggior parte dei posti in cui ho lavorato considera la possibilità di completare un'attività quasi completa come preziosa per continuare semplicemente, a meno che qualcosa non sia cambiato radicalmente. La pena di cambiare contesto spesso non vale la pena di cambiare l'ordine.

Monitoriamo il tempo trascorso nell'iterazione di sprint a scopo di capitalizzazione, (ore bruciate su attività correlate a una user story), e spostiamo la user story puntata se l'obiettivo del PO è quello di continuare a trasportarci su di esso durante il prossimo sprint, lasciando i punti lo stesso.

Se l'obiettivo del PO è spostare qualcos'altro al suo posto, allora semplicemente metteremo la storia incompiuta nell'arretrato e fare qualunque cosa volessero. Lasciare la stima originale dei punti è la mia raccomandazione, perché se avessi l'abitudine di mordere più di quanto potessi masticare, ogni sprint, avresti "completato" punti storia in uno sprint che non era completo e pulito- articoli testati.

Se volevi lasciare qualcosa nello sprint, puntato o che dovevi spedire, penserei che avresti determinato un punto di divisione all'interno della storia originale, a cui hai raggiunto il punto finale e commit quel pezzo più piccolo per la tua iterazione. Quindi il resto potrebbe essere nuovamente puntato e inserito nel backlog. Questa sarebbe un'opportunità da rivalutare perché hai concordato con la tua squadra di suddividere la storia in sezioni.

Given that the User Story we are carrying over is partially complete, how do we estimate for it correctly in the next Sprint Planning session?

Non penso che le opzioni da A a C siano buone, principalmente perché ciò che (penso) dovrebbe essere più importante per quanto riguarda la velocità di una squadra è la velocità media e non se la velocità di ogni dato sprint andato su o giù.

Quando viene definita una storia utente, dovrebbe avere criteri di accettazione. Se qualcosa nei criteri di accettazione è non fatto, la squadra semplicemente non guadagna nessuno dei punti. Se la storia è finita (cioè codificata, testata e accettata dal P.O.) la squadra ottiene tutti i punti.

Funziona bene quando il team è concentrato sulla sua velocità media piuttosto che sulla velocità di uno sprint.

Come M. Cohn nel suo libro, tendo ad avere una preferenza per uno scenario tutto-o-niente. Dopo tutto, provare a stimare se hai completato 5 punti su una storia di 8 punti, o forse solo 6 o 7 sta per finire per essere un altro gioco di ipotesi ... e non dimenticare che hai già ottenuto l'iniziale stimare via. Probabilmente è meglio andare con il metodo più semplice e ottenere tutti i punti dopo che è stato completato.

Citando M. Cohn dal suo libro¹ (la mia enfasi):

I’m generally in favor of an all-or-nothing stance toward counting velocity: if a story is done (coded, tested, and accepted by the product owner), the team earns all the points, but if anything on the story isn’t done, they earn nothing. At the end of an iteration, this is the easiest case to assess: If everything is done, they get all the points; if anything is missing, they get no points. If the team is likely to take on the remaining portion of the story in the next iteration, this works well. Their velocity in the first iteration is a bit lower than expected because they got no credit for partially completing a story. In the second iteration, however, their velocity will be higher than expected because they’ll get all of the points, even though some work had been completed prior to the start of the iteration. This works well as long as everyone remembers that we’re mostly interested in the team’s average velocity over time, not in whether velocity jumped up or down in a given iteration.

¹ Stima e pianificazione agile , Stima delle storie parzialmente completate, p.66

La mia squadra aveva precedentemente tentato di assegnare punti parziali, nonostante alcune obiezioni, e non penso che abbia funzionato affatto. (Non lo facciamo più ... vai a capire) Questo è particolarmente vero perché si suppone che le storie siano stimate come una squadra , ma se solo una persona ci sta lavorando, sarà essere più difficile per il team sapere quanto un individuo ha effettivamente completato. Agile è più interessato alla velocità media di una squadra piuttosto che a quanto "bello" assomiglia ad uno sprint particolare.

Detto questo, l'autore fa dice che l'assegnazione di punti parziali può essere presa in considerazione se è improbabile che la squadra affronta il lavoro rimanente nella successiva iterazione. In questo caso, il team dovrebbe stimare il lavoro che rimane e scomporlo in nuove storie di utenti con qualsiasi dimensione sentano di dover avere. Come cita l'autore²:

The combined estimates would not need to equal the original estimate...

² Idem, p.66

La migliore raccomandazione per il team è di abbattere le storie a dimensioni sufficientemente ridotte per evitare questo tipo di problema³:

However, the two best solutions to allocating points for incomplete stories are not to have any incomplete stories and to use sufficiently small stories that partial credit isn’t an issue.

³ Idem, p.67

Spero che questo aiuti.

La prima domanda da porsi è: cosa significa un punto della storia? Se definisci un punto della storia come "Quanta ingegneria del lavoro viene eseguita", allora qualsiasi risposta lo farà. Tuttavia, se definisci un punto della storia come "Quanto valore viene consegnato all'azienda", diventa importante non dare credito finché una storia non è completata al 100%, accettata e consegnata al 100%. Modificare i punti della storia dopo uno sprint basato su ciò che è stato completato nasconderà solo il vero problema: a) non c'era una chiara comprensione della storia, b) la storia era troppo definita grossolanamente, c) la storia mancava di criteri di accettazione misurabili, d ) non una comprensione abbastanza profonda dei compiti o delle dipendenze per completare la storia, e) sottovalutato lo sforzo di testare la storia, f) abbattuto troppi punti della storia, o g) ... inserire la ragione qui ...

L'obiettivo dell'agile deve essere flessibile pur essendo prevedibile. Il modo migliore per essere coerenti, secondo me, è capire cosa è andato storto senza modificare le stime della storia originale.