Cosa succede se non viene raggiunto lo Sprint Goal?

L'obiettivo dello sprint dovrebbe essere riposto nel backlog e quindi rivalutato insieme a tutte le altre storie nel backlog. Nella maggior parte dei casi, ciò significa che verrà assegnato un ordine di priorità alla parte superiore del backlog e verrà inserito nel prossimo sprint. In teoria, se le esigenze aziendali sono cambiate da quando l'arretrato è stato sottoposto a priorità, potrebbe essere lasciato per uno sprint successivo o addirittura buttato fuori. Ma il concetto chiave è che è trattato come qualsiasi altra storia nel backlog.

Se ciò accade spesso, è necessario rivalutare il modo in cui si scrivono le storie in quanto ciò significa che non si possono creare storie abbastanza dettagliate da essere terminate in un singolo sprint. Ma i capricci dello sviluppo significano che accadrà di tanto in tanto anche alla migliore squadra.

(Ho visto alcune squadre reagire a questa situazione dividendo la storia in due a questo punto, il primo è il lavoro che è stato completato e il secondo è il nuovo lavoro richiesto. Non mi piace perché penso che faccia sembrare le cose artificialmente buono dopo il fatto.)

Sembra che tu pronunci "Sprint Goal" e significhi "un bel po 'di qualcosa che il prodotto deve fare che attualmente non è così". Questa può essere una discussione separata su come creare migliori backlog di prodotti, tra cui epopee, temi, mappe di storie, ecc.

Per ora, qui ci sono cose su come migliorare:

1. Ottieni una migliore comprensione dello Sprint Goal
2. Trascorrere del tempo rimuovendo gli impedimenti al lavoro in decomposizione in dimensioni più gestibili
3. Craft Sprint Goals basati sul lavoro che può essere realizzato in un singolo Sprint

Posso aiutarti con # 1: D

Innanzitutto, lo Sprint Goal non esiste nel Product Backlog. Per la guida di Scrum, l'obiettivo di Sprint è

...an objective set for the Sprint that can be met through the implementation of Product Backlog.

Lo Sprint Goal è creato dall'intero team di Scrum (leggi: Product Owner, Development team e Scrum Master) dopo che il team di sviluppo ha previsto il lavoro che può essere svolto nel prossimo Sprint. Lo Sprint Goal può quindi essere inteso come:

...an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Ecco una rappresentazione visiva di come uno Scrum Team potrebbe gestire il lavoro di previsione dal Product Backlog, formare uno Sprint Goal, reagire a un lavoro imprevisto e raggiungere comunque il proprio Obiettivo di Sprint:

SeilProductOwnernonèingradodidefinireillavoronelProductBacklogperilqualeilteamdisviluppopuòprevedereilcompletamentoinunoSprint,nonpronunciare/doquantosegue:

• AllungaloSprint
• Dì,"Scrum non può funzionare qui"
• Porta il lavoro nello Sprint che i Team di sviluppo non possono terminare

Ironia della sorte, accorciare lo Sprint (decisione del proprietario del prodotto) costringerà molte volte gli Scrum Team a trovare modi innovativi per produrre pezzi più piccoli di software prezioso e funzionante.

Invece, chiedi "cosa dovrebbe cambiare?" Questo costruttivo conduce la discussione verso l'arte del possibile che a sua volta ci ispira a lavorare per il cambiamento.

Porta solo il lavoro in uno Sprint che il Dev. La squadra pensa di poter realizzare. Fare altrimenti invita la marcia della morte (brividi) .

La produzione di software di lavoro in 30 giorni o meno è uno degli aspetti più importanti dell'agilità che Scrum insegna. Per favore considera di rendere questi miglioramenti una priorità assoluta per la salute del team e dell'organizzazione.

Penso che questo dovrebbe essere discusso e post mortem nella Sprint Retrospective. Le conclusioni riguardanti lo scopo dello sprint ovviamente varieranno, ma alla fine la decisione di rinunciarvi o portarla allo sprint successivo dovrebbe appartenere al Product Owner.