È una nuova richiesta di modifica su una storia utente una diversa user story

Crea una nuova storia per il tuo nuovo requisito .

La domanda nel titolo potrebbe non avere una risposta generica, ma consideriamo il tuo esempio:

As a user I want to maintain a user profile

Supponiamo di avere una definizione di fatto per questa storia, inclusa la possibilità di modificare e salvare l'indirizzo di casa, il numero di telefono e alcune altre cose. Il proprietario del prodotto ha acconsentito, la storia è stata stimata e tirata in volata. Successivamente è stato contrassegnato come completato e i punti della trama sono stati guadagnati.

Se cambi questa storia, questo indurrà un cambio di scope della storia originale. Mostra anche un calo nel burndown, anche se hai consegnato un lavoro di alta qualità come concordato prima di riprenderlo. Vedi questa domanda correlata . Crea una nuova storia, accetta che sia piccola e inseriscila quando devi riempire lo sprint con qualcosa di piccolo.

Impara da questo e regola la tua definizione di ogni iterazione in modo che includa una volta prima della fine, per impedire aggiunte banali prima che sia troppo tardi.

Una volta che una storia è stata impegnata in uno sprint, quella storia non dovrebbe più essere modificata.

Ora, se l'utente presenta una nuova idea a metà dello sprint che influenzerebbe una delle storie di quello sprint, ci sono alcuni modi per gestirlo:

• Abort the sprint e inizia a pianificare un nuovo sprint. Questo ha un impatto enorme e di solito sarà un'opzione di ultima istanza. È utile soprattutto se le nuove idee del cliente invalidano completamente il lavoro attualmente in corso.
• Rimuovi le storie interessate dallo sprint . Se alcune storie sono invalidate da queste nuove idee e sono considerate con valore zero (o addirittura negativo), allora puoi decidere, in collaborazione con il cliente, di rimuovere quelle storie dallo sprint corrente. Il divario risultante nel lavoro potrebbe essere riempito con il lavoro dal backlog del prodotto.
• Aggiungi le nuove idee come storie . Questa dovrebbe essere l'opzione più comune. Se le storie originali hanno ancora valore, completale come pianificato e aggiungi le nuove idee come storie aggiuntive al backlog del prodotto.
• Se le modifiche sono molto secondarie (si tradurrebbe in una storia di < 1 story point) e la storia non è ancora stata completata, potresti decidere di prendere le modifiche insieme alla storia originale implementazione. Questa scelta dovrebbe essere rara.

Nel tuo esempio della storia "crea profilo", la storia aggiuntiva potrebbe essere che l'utente desidera memorizzare un collegamento Facebook insieme alle altre informazioni nel profilo.

La domanda se la modifica è una richiesta di modifica (che di solito viene fatturata separatamente) o rientra nel normale lavoro dipende dal contratto con il cliente e riguarda il gestore dell'account.

Non sono un esperto di Scrum (con qualsiasi significa), ma ho intenzione di [ingenuamente] dire che questa dovrebbe essere una nuova User Story.

• Hai già incontrato i tuoi criteri di accettazione su questa storia.
  Affrontare questo cambiamento potrebbe mettere a repentaglio questo risultato. (Probabilmente c'è un nuovo nome alla moda, ma noi abbiamo usato per chiamarlo "Scope Creep" e non è mai stata una buona cosa).

• L'aggiunta di un nuovo campo dati probabilmente significa cambiare l'archivio dati sottostante.
  Potrebbe essere o meno un lavoro "rapido", mettendo ancora a rischio i tuoi punti.

• Crea una nuova storia e mettila nel backlog, proprio come tutto il resto.
  Certo, sembra una buona idea (e davvero importante) quando si presenta ma, di fronte alla realtà di tutto ciò che altro ha bisogno di fare, potrebbe diventare [relativamente] meno importante.

• Dici questo:

  "un nuovo requisito che non ha alcun cambiamento nella definizione della storia utente"

  Bene, se è un Cambia ma non sta cambiando la definizione di questa storia, allora come può essere fatto come parte di questo Storia? Sicuramente deve essere [parte di] una storia la cui definizione cambia?

In termini di documentazione e gestione del cambiamento in un rigoroso framework Scrum, dovrebbe essere gestito come una nuova user story e non consentito nell'iterazione esistente, ma ...

Siamo pratici e non creare inutili spese generali ... non è Agile. Se la complessità / sforzo di codifica / test è così ridotta da richiedere più tempo per creare, assegnare priorità e gestire la nuova storia piuttosto che modificarla e completarla nella storia esistente, segui la strada più snella e aggiorna semplicemente la storia esistente.

Ricorda che, una volta eseguito un miglioramento, i tuoi sviluppatori potrebbero aver bisogno di riscaldarsi nuovamente con il codice prima di apportare la modifica. A volte è più efficiente solo apportare modifiche al volo e tracciare il cambiamento rispetto alla storia esistente.