Le attività o le storie "quasi finite" giustificano la pianificazione con sovraccarico nel prossimo sprint?

Quando una storia non viene eseguita alla fine dello sprint, i punti della trama non contano per la velocità di quello sprint e la storia torna sul backlog.

Se durante la pianificazione dello sprint successivo la storia viene selezionata per essere completata, è possibile eseguire una rapida rivalutazione del lavoro rimanente. Questa stima dovrebbe essere utilizzata solo durante la sessione di pianificazione per garantire che non si stia caricando lo sprint con storie con un numero elevato di punti in cui in realtà devono essere eseguiti pochissimi lavori per completarli.
Sulla scheda (e nella velocità del nuovo sprint), dovrebbe essere utilizzata la stima originale della storia che è stata riportata.

Tali storie riportate sono una delle ragioni per cui la velocità può variare da sprint a sprint e dovresti utilizzare una media per calcolare la capacità della squadra quando pianifichi uno sprint.

Se la storia non completata non viene ripresa nello sprint successivo, allora potrebbe essere meglio pianificarla per il valore pieno dei punti quando viene recuperata di nuovo, perché ci vorrà del tempo per alzarsi- riattivare di nuovo quello che era lo stato quando il team ha smesso di lavorarci sopra.

Non cercare di rendere la tua velocità un aspetto migliore di quello che è. La via da seguire è riconoscere che l'attività non è stata completata, hai sovrastimato ciò che potresti fare nello sprint e non è riuscito. Ma questa è la vita e un'opportunità per imparare.

Quindi 0 punti per l'attività incompleta.

Per quanto riguarda il nuovo sprint, stimare il lavoro necessario per completare l'attività nei punti storia e considerarlo come un compito normale.

Sei preoccupato che la tua velocità sembrerà troppo bassa, dovresti essere preoccupato che la tua velocità sia artificialmente troppo alta.

Avere una velocità superiore a quella che puoi effettivamente ottenere ti farà fallire ancora e ancora.

Nel nostro team utilizziamo diversi modi per gestire storie di riporto, a seconda delle circostanze.

• Quando lo sprint è quasi finito e tutto ciò che è pianificato è già terminato (il che accade ogni altro sprint), quindi iniziamo con le storie successive sul backlog (ma non li impegniamo per il rilascio sprint). Questi sono inclusi automaticamente nel prossimo sprint, e per scopi di reporting tutti i punti della storia passano allo sprint successivo.

• Quando parti della storia sono completamente finite e hanno valore di business per conto proprio, in generale riaggiustiamo sia la portata che la stima per la storia originale, e le parti rimanenti tornano all'arretrato.

• Se la stima originale per la storia era disattivata (cosa che a volte accade per storie grandi e complesse) cerchiamo di imparare da essa :). Nessun punto della storia nello sprint attuale, ri-stimare l'intera storia nella prossima pianificazione dello sprint.

Quando alcune delle storie passano dallo sprint precedente, nella pianificazione sprint non inizi con uno sprint vuoto. Il team decide quanto lavoro extra possono prendere in più. Ad esempio: normale capacità della squadra 100 SP / sprint, 20 punti già in corso, il team decide di prendere 90 nuovi SP, quindi hai 110 SP nello sprint all'inizio dello sprint.

Lo svantaggio principale di questo approccio è che i rapporti di velocità non sono così belli come piacerebbe a qualcuno dei manager. Ma alla lunga tutto si uniforma, e in questo modo tutto ciò che è potenzialmente rilasciabile viene consegnato il prima possibile e il team ottiene crediti per il proprio lavoro.

Un po 'di retroscena: in origine questo team aveva un approccio molto rigoroso alle scadenze, quindi si rifiutavano di affrontare storie più grandi di quelle che potevano finire entro la prima settimana (dello sprint 2-wk), e usare lavoro piccolo e sicuro per la parte restante dello sprint. Mentre questo ha portato ad un bel backlog di sprint vuoto alla fine dello sprint, questo ha avuto un'influenza eccessiva sulla domanda "su cosa dovremmo lavorare dopo?".

Questa non è una domanda per una risposta facile. Ci saranno molte opinioni su cosa fare, ma ti suggerisco di iniziare a identificare le varie esigenze che devi soddisfare e trovare una soluzione basata su quelle. Esempio:

1. Un team "ha bisogno" di capire come stanno funzionando e identificare eventuali opportunità di miglioramento. A volte, cambiare i punti della storia maschera le questioni che dovrebbero essere affrontate.
2. Il Product Owner "ha bisogno" di essere in grado di sapere quanti punti della storia sono stati stimati per una feature (spesso questi sono aggregati a livello di feature) o Release (AKA "PI" in SAFe-speak) e potrebbe chiedere un masterizzare a livello di funzionalità (o PI) per dimostrare i progressi verso la consegna di un MVP o MMF. Cambiare i punti della storia può distorcere i numeri e causare confusione.

Ci sono alcuni "guard rail" per aiutare a guidare la decisione.

• Il lavoro è FATTO o no. Il lavoro incompleto non conta allo sprint in cui è stato completato.
• Le storie incomplete dovrebbero essere riordinate per priorità (non è un "dato" che vengono trasferite al prossimo sprint, possono tornare al backlog o essere abbandonate).

Detto questo, ho visto molti team gestire questo in vari modi.

1. Se la storia incompleta è ancora valida e approvata dall'OP, l'intera storia porta allo sprint successivo. Ciò che queste squadre fanno spesso è TAG queste storie come riportare e stimare quanti punti di "lavoro rimanente" rappresentano. Quindi, se è una storia di 13 punti, ma ha solo 1 punto rimanente, fanno i calcoli per adattarsi in tal modo sottraendo 12. Ciò lascia la stima originale per scopi storici come suggerito, aiutando la squadra a capire la propria capacità. In questo caso, SÌ, potresti avere "più punti" rispetto alla "soglia" della capacità basata sulla velocità. Ma la velocità può cambiare leggermente, non è scritta in pietra.
2. Ho visto i team dividere la storia (Rally, ad esempio, ha una funzionalità molto bella per questo), e applicare alcuni punti per la parte della storia che "rimane" nel vecchio sprint e quindi applicare i punti alla parte che porta avanti. Questo approccio è conveniente, ma viola il principio secondo cui "Fatto è FATTO" e nasconde il fatto che le stime possono essere carenti e il lavoro sta continuando, quindi l'opportunità di imparare e migliorare può essere persa. (Questa non è la mia raccomandazione per questi motivi)
   3. La soluzione peggiore che ho visto è che hanno appena segnato la vecchia storia FATTO, forse hanno ridotto i punti, forse no, e poi hanno aperto una nuova storia per il lavoro rimanente (spesso testando!). Questa è una brutta soluzione con qualsiasi standard, IMHO.

Ciò su cui vorrei concentrarmi è questo: "Uno di questi è un classico" fatto al 90% "con un numero piuttosto elevato di punti narrativi" - la chiave qui è la GRANDE storia! Ricorda INVEST: le storie dovrebbero essere PICCOLE. La squadra dovrebbe guardare le storie divise (preferite) o sciamarle. Ma più grande significa sempre più rischio, anche quando brulica.