A volte cambiamo l'ambito della storia dell'utente per completarlo durante l'iterazione. Ad esempio,
Storia originale (8 punti): come utente voglio salvare i miei dati in formato PDF.
Storia de-Scoped: come utente voglio salvare i miei text dati come PDF.
Ora devo ridurre anche la dimensione della storia de-scoped?
Modifica
Che cosa fai in questi casi e perché?
Dipende.
Quando una storia viene decifrata per qualsiasi motivo, ci chiediamo all'interno del team, " La complessità della storia rimane la stessa? " Se la risposta è SI, quindi nessun cambiamento in la sua stima Se tuttavia la complessità cambia, la stima varia di conseguenza. La stima è direttamente proporzionale alla complessità :)
Se si taglia una storia a metà per adattarla all'iterazione, è meglio creare un'altra storia per il lavoro rimanente e quindi stimare nuovamente entrambe le storie. (Anche se non pianifichi mai la nuova storia, è disponibile.)
Questo è molto più facile da fare se le tue stime sono di dimensioni piuttosto che di ore.
Non hai , ma non farebbe male riscriverlo ogni volta che si verificano cambiamenti. In questo modo la tua storia stima in modo più accurato il lavoro che devi svolgere e ti consente di inserire qualcos'altro nel caso in cui la portata della storia venga ridotta o ti guidi a eliminare qualcosa se l'ambito della storia viene ingrandito.
Se la tua storia è ora di portata inferiore, dovresti anche creare una nuova storia (o più) per acquisire i requisiti che sono stati esclusi dai criteri di accettazione e stimare di conseguenza una nuova storia.
Il team che presento fa più o meno quanto sopra. Se scopriamo che la storia come scritta risulta troppo grande per essere ragionevolmente completata, abbiamo diviso il lavoro che può stare da solo in una nuova storia.
Tuttavia, non sempre ri-stimiamo la vecchia storia. Dipende da quanto siamo lontani dal lavoro e qual è il campo di applicazione rimanente. A volte risulta che stiamo ancora facendo la parte del leone del lavoro e mentre la storia potrebbe non valere più 8 punti, è ancora troppo grande per essere una storia di 5 punti.
(Raramente abbiamo storie più grandi di una 3 programmate per un'iterazione, ma sto cercando di usare i numeri indicati nella domanda per qualche contesto.)
La nuova storia ottiene sempre una nuova stima. Le storie che non vengono eseguite entro la fine di un'iterazione completata per qualsiasi motivo e non possono essere divise finiscono "rollate" in un'altra iterazione e li ricostituiamo a quel punto per tenere conto della riduzione dello scope grazie al lavoro già svolto (se ce ne sono).
Stai provando a risolvere il problema che non dovrebbe accadere in primo luogo.
Se la trama è delimitata, è stata definita o valutata in modo errato e non avrebbe dovuto essere pianificata affatto (o l'impegno era sbagliato). Questa è la prima regola da seguire. Se la storia non contenesse criteri di accettazione che dicessero che è possibile salvare solo "testo come PDF", ha semplicemente coperto tutto e avrebbe dovuto essere dimensionato in quel modo e quella dimensione avrebbe dovuto essere presa in considerazione durante la pianificazione.
La storia di decodifica durante lo sprint è errata. Impegni sulla storia originale e consegni o meno quella storia originale. Puoi discuterne con il proprietario del prodotto e:
In entrambi i casi la storia originale rimane invariata durante lo sprint corrente e viene contrassegnata come non eseguita. I motivi per questo possono essere diversi
Leggi altre domande sui tag estimation scrum user-story