In che modo il risultato della revisione del Product Backlog durante Sprint Review influenza il successivo Sprint's Backlog?

3

Su scrumguides.org , si dice quanto segue sul risultato di un Sprint Review :

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

Tuttavia, una Sprint Review è qualcosa che fai alla fine di uno Sprint, il che significa che il prossimo sta per iniziare e gli articoli principali del Product Backlog dovrebbero già essere pronti per questo.

In che modo la revisione di un Product Backlog durante Sprint Review influenza il successivo Backlog di Sprint? Le modifiche sono state apportate durante l'analisi tipicamente utilizzata nelle modifiche dell'ultimo minuto al Backlog di Sprint successivo? Il proprietario del prodotto e il team di sviluppo hanno entrambi voce in capitolo su come viene regolato il prossimo Sprint? Oppure le revisioni al Product Backlog in genere non influenzano il prossimo Sprint (ma supera quello dopo quello)?

Ho provato a rispondere alla mia domanda leggendo attentamente la guida di cui sopra, ho controllato domande simili e suggerito duplicati su programmers.se, ma non ho ancora trovato una risposta autoritaria.

    
posta Jeroen 13.05.2015 - 12:01
fonte

2 risposte

2

I sottoprodotti della revisione sprint includono un possibile cambio alla velocità media e un feedback da parte dello stakeholder. Il feedback potrebbe essere "no, non è quello che volevo" o "eccellente! Usiamo il design per il resto dell'app!". Tutto ciò può potenzialmente modificare gli articoli o l'ordine degli articoli sul backlog.

Are changes during Review typically used in last-minute changes to the next Sprint's Backlog?

Non direi tipicamente , ma può succedere. Il motivo della revisione è assicurarsi che tu soddisfi le esigenze degli stakeholder. L'intero punto di agilità è quello di essere in grado di adattarsi alle mutevoli esigenze, e la revisione è forse il primo posto in cui diventa evidente la necessità di un cambiamento.

    
risposta data 13.05.2015 - 13:28
fonte
0

Mi sono imbattuto in questo e in analoghi problemi in scrum, fondamentalmente penso che questo dipenda dal fatto che tu abbia un periodo di tempo in cui non viene eseguito alcun "lavoro" (in termini di attività sulla scheda) tra gli sprint

Alcuni team passeranno direttamente al prossimo sprint con solo un paio di brevi riunioni

Alcuni team avranno una pausa di un paio di giorni tra gli sprint in cui fanno le varie riunioni, ordinano il back log, la stima ecc.

Alcuni team avranno intere settimane o forse scarichi di bug di rilascio / bug tra gli sprint "normali"

Personalmente ritengo che l'opzione "senza interruzioni" sia la migliore. Diminuisce l'importanza degli incontri e degli artefatti in favore del progresso delle attività e incoraggia tutti i compiti a essere inseriti nel backlog piuttosto che avere compiti speciali, non di sprint

Speriamo che il tuo Scum master abbia ordinato il backlog durante lo sprint precedente e che possa essere rapidamente riordinato senza esaurire le attività ben definite / bene stimate.

    
risposta data 13.05.2015 - 12:11
fonte

Leggi altre domande sui tag