Come gestire una storia utente che è significativamente più grande di quanto stimato

La mia raccomandazione sarebbe quella di rimuoverlo dallo sprint corrente e quindi continuare lo sprint come al solito. Non "backfill" lo sprint (anche se, non sono sicuro al 100% da cosa intendi con questo). Se finisci tutto prima che lo sprint sia finito, a quel punto puoi fare quello che fai normalmente quando hai un tempo extra, il che potrebbe essere quello di introdurre una storia più piccola. L'importante è finire tutto il resto prima di portare nuove storie nello sprint.

Dato che c'è un po 'di tempo in più nello sprint, qualcuno (o chiunque) può lavorare con il proprietario del prodotto per aiutare a dividere questa storia più grande in storie più piccole. Queste storie possono quindi essere considerate per i seguenti sprint.

Per quanto riguarda il collegamento dell'epica alla storia originale, non sono sicuro che importi. L'obiettivo finale della squadra è lavorare con il software piuttosto che con una pila di vecchie carte della storia. Se è utile tenerlo, tienilo. Non c'è nulla nella guida di misericordia che suggerisca di tenerlo o di buttarlo via. Fai ciò che aiuta la tua squadra.

Se fosse la mia squadra, probabilmente la terrei e la attaccerei alla tavola di mischia con del nastro adesivo, per fungere da artefatto storico e un promemoria su quanto a volte può essere difficile la stima.

L'obiettivo di uno sprint non è quello di completare storie, ma di fornire valore, ovvero software funzionante. Il valore delle storie è determinato dal proprietario del prodotto, ma la loro priorità dipende dalla stima del team dello sforzo richiesto. Se diventa evidente che una storia è stata selvaggiamente sottovalutata, le priorità potrebbero cambiare.

Se ti rendi conto dei problemi all'inizio dello sprint, rinomina i contenuti dello sprint con il proprietario del prodotto. Non hai intenzione di completare quella storia enorme - cosa vorrebbero invece? Come puoi utilizzare lo sprint rimanente per fornire il massimo valore?

Questo non è sempre possibile perché il lavoro richiede tempo e alcuni di questi tempi sono già passati. Soprattutto se i problemi compaiono in ritardo nello sprint, abbandonare la storia e concentrarsi sul resto sarà migliore.

In nessuna circostanza una storia sottovalutata può ostacolare il progresso su altre storie. Concentrati sugli obiettivi raggiungibili al fine di fornire più valore possibile alla fine dello sprint. Se alla fine si finisce con un po 'di tempo in più, è possibile utilizzare un po' di tempo per cercare il problema in modo più dettagliato.

In futuro, ora disponi di informazioni sufficienti per analizzare il problema e stimare i suoi prossimi passi? Altrimenti, prendi in considerazione un spike , un esperimento time-box durante lo sprint successivo. I picchi non ottengono punti storia e il tempo utilizzato per loro non è disponibile per il lavoro sulle funzionalità in modo da ridurre la velocità. Il risultato di un picco è una migliore comprensione del problema.

Cerca di non lasciare storie se possibile.

Se lasci cadere le cose perché è difficile allora mette davvero in discussione la motivazione a fare qualsiasi delle storie.

Metti questi compiti perché fanno soldi per il business giusto? Stai dicendo che il valore era inferiore a 6 settimane di tempo di sviluppo. È ridicolmente basso dato che il prodotto sarà in servizio per anni.

Ci sono alcune situazioni in cui le funzionalità perdono valore se perdono una scadenza, o stai lanciando un omaggio per mantenere un cliente felice perché pensavi che fosse economico. O forse il budget è troppo stretto.

Tuttavia, se stai dedicando attività che non hanno reali esigenze di business, qualcosa è andato storto.

Raccomando di mantenere il compito e di dedicare il tempo necessario al refactoring e farlo accadere. Oppure dare ai tuoi requisiti la raccolta e la definizione delle priorità di un aspetto molto difficile.