Scrum: come gestire gli oggetti arretrati che sono più lunghi di uno sprint

Sto iniziando con SCRUM e ho un problema a capire una cosa. In che modo SCRUM gestisce gli oggetti arretrati che richiedono più di uno sprint?

Tali elementi sono chiamati Epic e devono essere divisi in storie utente più piccole che sono più brevi di un singolo sprint e per questo motivo possono essere pianificate, o Tema che sarà diviso in Epiche e quelle in storie comuni. Epici e temi condividono la caratteristica principale - alto livello di incertezza = non possono essere adeguatamente stimati (la stima è di solito molto alta e per questo motivo non rientrano in un singolo sprint).

Quindi è bene iniziare con tali storie, ma non è possibile pianificarle finché il proprietario del prodotto non le suddivide in storie specifiche più piccole. Queste storie vengono utilizzate solo per prendere nota di alcune funzionalità richieste più grandi (Epica) o di interi set di funzionalità (Tema). La rottura di queste storie renderà la funzionalità specifica.

Segue anche la struttura Iceberg del portafoglio ordini del prodotto.

Non hai tali oggetti. In tal caso, l'elemento backlog non è abbastanza specifico e non è stato suddiviso correttamente in elementi più piccoli. Alcune persone li chiamano non arretrati, ma elementi fatlog e in Scrum sono considerati un anti-pattern.

La storia dell'analogia della torta: come mangiatore di torte, voglio mangiare una torta nel pomeriggio. Non riesco a mangiare un'intera torta in un pomeriggio, quindi deve essere tagliata per adattarsi alla quantità che posso mangiare.

Quando Scrum è stato "inventato" per la prima volta, lo sprint predefinito era normalmente di 4 settimane.

Secondo quanto mi è stato detto, la ragione di questa lunghissima dimensione dello sprint era semplicemente perché le persone in quel momento avevano difficoltà a immaginare di poter realizzare qualsiasi cosa in sprint più brevi.

Man mano che i team diventavano più sicuri della mischia, hanno imparato a dividere meglio gli oggetti arretrati in oggetti più piccoli di dimensioni più gestibili, e i team di sviluppo sono migliorati non esagerando con il design iniziale, ma facendo semplicemente abbastanza.

Oggi, credo che la maggior parte delle squadre considererebbe 4 settimane di durata dello sprint molto lunga. Ho l'impressione che 2 settimane siano abbastanza normali. I team XP eseguono solo 1 settimana di iterazioni e completano le storie utente complete in ogni iterazione.

Quindi è necessario essere migliori nel dividere gli articoli in arretrato in articoli più piccoli, in modo che ciascuno dia un piccolo incremento del valore aziendale al prodotto finale. È possibile, ciò è stato dimostrato. (anche se non escluderò che potrebbero esserci domini molto specializzati dove sarebbe difficile)

Sono d'accordo con 4 settimane di essere un lungo sprint in questi giorni. Volete ridurre il circuito di feedback e migliorare nel girare piccole unità di lavoro in iterazioni più brevi. In questo modo c'è meno da sbagliare, meno che cambierà e meno complessità da gestire in una volta sola.

Dividere le storie è spesso un'area problematica per le persone, ma ci riesci meglio, più lo fai. Lavora a stretto contatto con l'OP per capire se puoi consegnarlo in più fasi e continuare a fornire valore nello sprint.

Ecco un grande poster che aiuta a dividere le storie, è da un sito web chiamato agileforall.com e puoi trovare il poster qui, è davvero utile averlo aggiornato mentre affini gli oggetti arretrati:

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

È anche utile avere la tua definizione di fatto disponibile quando perfezioni e pianifichi in modo da poterlo tenere a mente quando ti impegni a completare qualcosa in un breve sprint.