Scrum: come portare una User Story parzialmente completa al prossimo Sprint senza distorcere l'arretrato

Stiamo usando Scrum e occasionalmente scopriamo che non possiamo ancora completare una User Story nello sprint in cui è stata pianificata. In vero stile Scrum, spediamo comunque il software e consideriamo di includere la User Story nel prossimo sprint durante la prossima sessione Sprint Planning. Dato che la User Story che stiamo portando avanti è parzialmente completa, come possiamo stimarla correttamente nella prossima sessione di Sprint Planning? Abbiamo considerato:

a) Regolazione del numero di Story Story in basso per riflettere solo il lavoro che resta per completare la User Story. Sfortunatamente questo causerà un errore nel riportare il Product Backlog.

b) Chiudere la User Story parzialmente completata e crearne una nuova per implementare il resto di quella funzione, che avrà meno Story Story. Ciò influenzerà la nostra capacità di vedere retrospettivamente ciò che non abbiamo completato in quello sprint e sembra richiedere un po 'di tempo.

c) Non preoccuparti di a o b e continua a indovinare durante Sprint Planning dicendo cose come "Beh, User Story potrebbe essere punti X della storia, ma so che è finito al 95%, quindi sono sicuro che possiamo adattarlo."

Nella mia squadra attuale facciamo c).

La velocità dovrebbe tenere conto delle cose che la squadra ha davvero finito nello sprint. Qualcosa che non è stato consegnato non ha alcun valore per il cliente, quindi non contiamo alcun punto per questo, è tutto o niente.

Quindi passiamo l'intera storia incompiuta allo sprint successivo e tutti i suoi punti della storia verranno aggiunti alla velocità dello sprint successivo. Le velocità si uniformano nel tempo e prendiamo una media dei pochi sprint precedenti come riferimento per determinare le velocità future stimate.

L'opzione A è una linea d'azione comunemente raccomandata. Non si assegnano punti per il completamento della storia per lo sprint precedente e per spostare la storia nel backlog del prodotto, dove viene ridistribuita. Calcoli la tua velocità (e altre metriche) in base alle storie degli utenti completate e al valore aggiunto. Quando inizi a pianificare il prossimo sprint, prendi le storie con la massima priorità in base al loro valore (che potrebbe o meno includere la storia incompleta, se le priorità aziendali sono cambiate). Quando si valuta la storia, includere il lavoro che è già stato svolto durante il factoring nella nuova quantità di punti per la storia.

Naturalmente, un'opzione alternativa (e la mia preferenza) sarebbe quella di utilizzare il numero stimato originale di punti della storia, che è qualcosa che ho fatto in passato. Questo presuppone che la tua stima sia buona e fondata, ma hai tirato giù troppo lavoro per lo sprint (ad esempio - la storia valeva effettivamente 3 punti, ma il problema sta nel fatto che hai tirato giù 15 punti della storia quando avresti dovuto solo abbattere 13). È un presupposto potenzialmente pericoloso se non si è sicuri della propria capacità di eseguire le stime, ma potrebbe funzionare in base al proprio team e al proprio processo.

Tuttavia, lei afferma che ciò "incasinerà la segnalazione del Product Backlog". Il Product Backlog dovrebbe essere comunque dinamico, con l'ordinamento e le stime di ogni storia che cambiano man mano che si capisce di più sulla tecnologia, sul sistema, sui requisiti e sul cliente. In genere, ciò che viene riportato dal Product Backlog è il numero di storie utente e il numero totale di punti trama. Questi dovrebbero cambiare quando cambiano le priorità, vengono aggiunti nuovi requisiti, vengono rimossi i requisiti non validi e vengono acquisite ulteriori informazioni.

Pensare troppo a questo fa sembrare più complicato di quanto non sia ... In realtà è piuttosto semplice:

Opzione C

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

Se aiuta, puoi tracciare una metrica "lavoro rimanente" separata per la storia dell'utente, in modo che se, alla fine dello sprint, la storia non è completa, il lavoro stimato rimanente può essere annotato sulla storia e preso in considerazione quando pianificandone l'inclusione in uno sprint successivo. Ma anche allora, non alterare il valore in punti della storia originale.

Se il tuo strumento di reporting non è in grado di gestire accuratamente l'opzione A, sceglierei l'opzione B a meno che tu non abbia alcuna speranza di utilizzare le tue metriche.

In alcuni casi puoi fare l'opzione B E non inclinare ciò che significa chiuso restringendo l'ambito della vecchia attività che stai per chiudere e creando solo una nuova attività per l'ambito che rimane. Questo rende la storia più sensata semanticamente e di solito indica i luoghi in cui avresti dovuto considerare di scomporre ulteriormente l'attività. A volte questo non è possibile o logico e hai semplicemente un compito che è così grande o si imbatte in quel livello di problemi.

modifica: questo presuppone (come ritengo che il PO stesse assumendo) che il lavoro quasi completo non è stato abbattuto in via prioritaria e che arrivare al risultato dello sforzo precedente lo mantiene abbastanza in alto nell'elenco per continuare a lavorare. So che alcuni negozi non lo fanno, ma la maggior parte dei posti in cui ho lavorato considera la possibilità di completare un'attività rimanente quasi completa per essere abbastanza preziosa per continuare semplicemente a meno che qualcosa non sia cambiato radicalmente. La pena di cambiare contesto spesso non vale la pena cambiare l'ordine.

Dato che la User Story che stiamo portando avanti è parzialmente completa, come possiamo stimarla correttamente nella prossima sessione di Sprint Planning?

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 un determinato sprint è aumentata o diminuita.

Quando viene definita una user story, dovrebbe avere criteri di accettazione. Se qualcosa nei criteri di accettazione non viene fatto, la squadra semplicemente non guadagna alcun punto. Se la storia è fatta (cioè codificata, testata e accettata dall'OP), la squadra ottiene tutti i punti.

Funziona bene quando il team è focalizzato sulla sua velocità media piuttosto che sulla velocità di un dato sprint.

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

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

Sono generalmente favorevole a una posizione del tutto o niente verso il conteggio della velocità: se una storia viene eseguita (codificata, testata e accettata dal proprietario del prodotto), il team guadagna tutti i punti, ma se qualcosa nella storia non lo è Fatto, non guadagnano nulla. Alla fine di un'iterazione, questo è il caso più semplice da valutare: se tutto è fatto, ottengono tutti i punti; se manca qualcosa, non ottengono punti. Se è probabile che il team affronti la parte rimanente della storia nella prossima iterazione, funzionerà bene. La loro velocità nella prima iterazione è un po 'più bassa del previsto perché non hanno ottenuto credito per aver completato parzialmente una storia. Nella seconda iterazione, tuttavia, la loro velocità sarà maggiore del previsto perché otterranno tutti i punti, anche se alcuni lavori erano stati completati prima dell'inizio dell'iterazione.Funziona bene finché tutti ricordano che siamo per lo più interessati alla velocità media della squadra nel tempo, non al fatto che la velocità salti su o giù in una data iterazione.

¹ Stima e pianificazione agili , rivalutazione di storie parzialmente completate, p.66

La mia squadra aveva già tentato di assegnare punti parziali, nonostante alcune obiezioni, e non credo che abbia funzionato affatto. (Noi non lo facciamo più ... vai a capire) Questo è specialmente il caso perché le storie sono supposti per ottenere stimato come una squadra , ma se solo una persona sta lavorando su di esso, sarà più difficile per la squadra di sapere quanto un individuo ha effettivamente completato. Agile è più interessato alla velocità media di una squadra piuttosto che a quanto "bello" sembra un determinato sprint.

Detto questo, l'autore fa menzione che l'assegnazione di un punteggio parziale può essere considerato se la squadra è improbabile per affrontare il lavoro rimanente nella successiva iterazione. In questo caso, il team stimerebbe il lavoro rimanente e lo suddividerebbe in nuove storie utente con qualsiasi dimensione ritengano di dover avere. Come cita l'autore²:

Le stime combinate non dovrebbero essere uguali alla stima originale ...

² Idem, p.66

La migliore raccomandazione per il team è quella di scomporre storie di dimensioni sufficientemente piccole per evitare questo tipo di problema³:

Tuttavia, le due migliori soluzioni per assegnare punti per storie incomplete non devono avere storie incomplete e usare storie sufficientemente piccole che il credito parziale non è un problema.

³ Idem, p.67

Spero che sia di aiuto.

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

Dato che non ci è sembrato che manchi nulla di ovvio, abbiamo pensato che questa fosse una di quelle decisioni che ogni squadra deve prendere per sé in base a come vogliono lavorare e quali parametri sono più importanti per loro.

Abbiamo deciso che è essenziale tenere registri accurati delle storie degli utenti che abbiamo implementato, in quanto costituiscono la base per i nostri test, la documentazione di supporto e le note di rilascio - che esclude l'opzione B.

Successivamente abbiamo pensato che essere in grado di eseguire con precisione la pianificazione dello sprint fosse essenziale - che esclude l'opzione C.

Abbiamo pertanto concluso che l'opzione A è giusta per noi. Stimeremo nuovamente i punti della storia per tutte le storie che completiamo parzialmente in uno sprint in modo da poterle pianificare correttamente negli sprint successivi. Con il passare del tempo, l'arretrato del prodotto riporterà leggermente la quantità di punti della storia che abbiamo implementato, ma questo sarà meno un problema rispetto a qualsiasi altra opzione e potrebbe eventualmente essere risolto modificando la nostra tenuta dei registri e i rapporti.

Tracciamo il tempo trascorso nell'iterazione dello sprint a fini di capitalizzazione (ore bruciate su attività correlate a una user story) e spostiamo la user story puntata se l'obiettivo dell'OP è quello di continuare a trasportare su di essa durante lo sprint successivo, lasciando punti uguali.

Se l'obiettivo dell'OP è di spostare qualcos'altro al suo posto, semplicemente inseriremmo la storia incompiuta nel backlog e faremmo tutto ciò che volevano. Lasciare la stima originale dei punti è la mia raccomandazione, perché se avessi l'abitudine di mordere più di quanto potresti masticare, ogni sprint, "sprecheresti" i punti della storia in uno sprint che non sono stati fatti e puliti completamente- articoli testati.

Se volessi lasciare qualcosa nello sprint, indicato, o se dovessi spedire, penso che determineresti un punto di divisione all'interno della storia originale, a cui hai raggiunto il punto finito e commettere quel pezzo più piccolo per la tua iterazione. Quindi il resto può essere ri-puntato e rilasciato nel backlog. Sarebbe un'occasione per rivalutare perché hai concordato con il tuo team di spezzare la storia.

La prima domanda da porsi è: cosa significa un punto storia? Se definisci un punto della storia come "Quanto lavoro di ingegneria viene svolto", allora qualsiasi risposta farà. Tuttavia, se si definisce un punto della storia come "Quanto valore viene consegnato all'azienda", diventa importante non dare credito finché una storia non viene completata, accettata e consegnata al 100%. La modifica dei 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 grossolanamente definita, c) la storia mancava di criteri di accettabilità 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, oppure g) ... inserisci qui la tua ragione ...

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