Come registrare le modifiche alle attività nel backlog sprint?

L'obiettivo se SCRUM è la trasparenza. Se la tua squadra ha in atto un processo di approvazione, un'attività non viene eseguita fino a quando non viene approvata. Tutte le ore lavorate per il completamento di tale compito devono essere registrate. Una soluzione semplice è scritta nel numero extra di ore (ad esempio, ogni volta che fai più lavoro aggiungi "+1" o "+4" all'attività.

L'altra scelta, come hai suggerito, è aggiungere un'altra attività. Dato che questo accade molto, forse è necessario includere un compito extra in ogni storia per questo tipo di lavoro. Se sai che succede, dovresti averne una pianificazione. Aggiungi un'attività chiamata "lavoro post-revisione" e valuta quante ore spendi in media. Fai quella parte del piano.

this additional work/changes certainly shorten the time for other stories pending"_.

Se con ciò intendi che riduce il tempo rimanente per altre storie, allora sì, lo fa. Non so cosa intendi con "come affrontiamo questa situazione?". Ne hai a che fare registrando tutte le informazioni pertinenti. Se arrivi alla fine dello sprint e alcune attività non sono terminate, ne parli nella retrospettiva e poi lavori sulle attività durante il prossimo sprint.

La linea di fondo è che è necessario tenere traccia di tutto il tempo trascorso (o interrompere del tutto il tempo di tracciamento e concentrarsi su punti della storia e storie più piccole). Quando finisci il tempo, parlane durante la retrospettiva e trova una soluzione che funzioni per la tua squadra, quindi prova a fare meglio il prossimo sprint.

Come ha sottolineato @Martin Maat, stai permettendo il cambiamento dell'ambito delle storie degli utenti durante lo sprint, non è una buona pratica (può essere anche da PO, non importa). Se questo accade spesso, può essere frustrante per il team e rende molto difficile pianificare i rilasci.

Mettendo da parte questo, possiamo generalizzare la situazione poiché in Scrum le attività possono emergere mentre il team ne sa di più e non è strano che alcune attività appaiano appena.

In tal caso, vorrei semplicemente creare un altro compito e stimarlo. Questo compito aggiuntivo che non era previsto in precedenza può essere visualizzato sul grafico di burndown al di sotto della linea zero. Questa è una tabella di rilascio nello stesso modo, ma si ottiene l'idea.

In questo modo puoi tenere traccia di quanto masterizzi dalle stime previste e di quanto hai aggiunto in cima (sotto). Come ha scritto @Bryan Oakley, la trasparenza è molto importante. In questo modo sarà visibile quanto spendi per i risultati aggiuntivi ogni sprint e in base a questo aggiusti il tuo modo di lavorare.

In uno dei commenti scrivi

In scrum constant feedback is important

Non sono sicuro che sia completamente così. Il feedback frequente è importante, ma poiché la situazione sta cambiando velocemente, può succedere che l'utilizzo di una user story a feedback costante non finirà mai perché il cliente cambia continuamente idea. Prova a correggere l'ambito all'inizio dello sprint. Non riesco a immaginare come pianifichi gli sprint: ciao squadra, puoi finire queste cinque storie di utenti nelle prossime due settimane, ma tenendo presente che l'ambito può cambiare in modo significativo? Sembra strano. + - + Ma forse ti ho sbagliato.

Non stai facendo Scrum. Potrebbe essere agile, ma il modo in cui lasci che i tuoi stakeholder interrompano lo sprint sconfigge completamente lo scopo di Scrum. Scrum sarebbe d'accordo su alcune funzionalità da costruire, quindi la costruirà come il team ritiene sufficiente nello sprint di uno sprint e quindi, al momento della revisione / demo alla fine dello sprint, presenterà i risultati alle parti interessate. Se i stakehokders a quel punto non sono soddisfatti, una nuova user story che soddisfa i loro desideri può essere presa nel prossimo sprint.

Lo scopo di Scrum è misurare quanto bene stai facendo in termini di aspettative e gradualmente migliorare. Il modo in cui lo stai facendo lo rovina, non stai lavorando per soddisfare la tua pianificazione di sprint, ti lasci micromesticare e correre dietro a un bersaglio mobile. Alla fine di uno sprint non c'è niente da confrontare perché non hai lavorato per soddisfare la tua pianificazione.

Dovresti smettere di fingere di fare Scrum e sbarazzarti di tutto ciò che fai ora per farti sentire che stai facendo Scrum (perché è uno spreco), o chiedere educatamente ai tuoi stakeholder di fare marcia indietro e salvare le recensioni per il giorno della dimostrazione.