Come gestire User Story alla fine dello sprint se gli utenti vogliono modifiche?

Presentarsi con nuove idee dopo essere stato presentato come nuovo lavoro finito è parte di un normale sviluppo iterativo. La cosa più importante è se la storia porta ciò che sapevi quando hai iniziato lo sprint. Nuovi approfondimenti sono per nuove storie.

Tenere storie aperte o rifiutare storie è per quando hai sbagliato qualcosa o hai perso le cose che hai discusso.

Quindi sicuramente l'opzione A.

Si riduce alla tua "definizione di fatto". La tua storia è fatta secondo questa lista?

La mia opinione però è di considerare la trama originale e dovresti crearne una nuova per il prossimo sprint.

Ma ancora più importante: impara da questo e trova un modo per evitare che accada di nuovo. Riunione retrospettiva potrebbe essere un buon posto per tirarlo su. Scommetto che più feedback degli utenti potrebbero avere qualcosa a che fare con questo:)

Btw, congratatta per il tuo primo sprint!

Sicuramente voterei per avere una nuova storia. A meno che la tua definizione di Done non comprenda che il client lo accetta, indipendentemente dai criteri di accettazione, stai osservando nuovi requisiti e vorrei monitorare e dare la priorità alle nuove modifiche separatamente dalla storia originale.

Ad esempio, potrebbero voler modificare Story A che hai appena terminato, quindi puoi creare Story X. Tuttavia, non vuoi affrontare Story X se il cliente preferisce andare avanti e ottenere una nuova funzione con Story B per prima cosa, e gestisci i loro ritocchi più tardi se c'è tempo.

La presenza di elementi di lavoro separati consente questa separazione delle priorità.

Gran parte dipende da quanto sono grandi i cambiamenti e da quanto è alta la priorità delle modifiche. Il cliente accetterà la funzionalità poiché sa che cambierà il prossimo sprint? Non accetteranno la funzione così com'è?

La risposta a queste domande guiderà ciò che farai dopo, A o B.

Per quanto riguarda la stima, farei attenzione a perdere la stima originale. Se perdi la stima originale, avrai difficoltà a capire la tua velocità effettiva per ogni sprint in cui devi modificare la stima.

Se usi uno strumento come JIRA che ti permette di collegare le attività insieme, vorrei registrare una nuova attività con i tweaks richiesti, collegarla all'altro ticket e inserirla in questo sprint backlog (assumendo che tu stia lavorando come parte di questo sprint).

Altrimenti potresti inserire una nota sul biglietto originale con il valore combinato del punto storia.

Devo raccomandarti per il tuo atteggiamento nei confronti del cambiamento. Se non sei in grado di accettarlo e scopri come far scorrere il tuo processo con esso, avrai sempre retroscena su come puoi pianificare di più per assicurarti di non perdere più nulla. Trovo che ti mancherà sempre qualcosa e l'approccio migliore è ottenere la funzionalità nelle mani dei clienti in anticipo e spesso e quindi fare esattamente ciò che stai suggerendo di fare, Iterate.