Sto iniziando con SCRUM e ho un problema a capire una cosa. In che modo SCRUM gestisce gli elementi del backlog che impiegano più tempo di uno sprint?
Sto iniziando con SCRUM e ho un problema a capire una cosa. In che modo SCRUM gestisce gli elementi del backlog che impiegano più tempo di uno sprint?
Tali elementi sono chiamati Epic e devono essere divisi in storie di utenti più piccole, più brevi di un singolo sprint e, a causa di ciò, possono essere pianificate, o Tema che sarà suddiviso in Epiche e quelli in storie comuni. Epics e Themes condividono la caratteristica principale: un alto livello di incertezza = non possono essere stimati correttamente (la stima è solitamente molto alta e per questo non rientrano in un singolo sprint).
Quindi è bene iniziare con tali storie ma non è possibile programmarle finché il proprietario del prodotto non le suddivide in storie specifiche più piccole. Queste storie vengono utilizzate solo per prendere nota di alcune funzionalità più richieste (Epic) o di interi set di funzionalità (Tema). La rottura di queste storie renderà la caratteristica specifica.
Segue anche la struttura Iceberg del backlog del prodotto.
Non hai questi articoli. In tal caso, l'elemento del backlog non è sufficientemente specifico e non è stato suddiviso correttamente in elementi più piccoli. Alcune persone non li chiamano backlog, ma fatlog e in Scrum sono considerati anti-pattern.
La storia dell'utente dell'analogia della torta: Come mangiatore di torte, voglio mangiare la torta nel pomeriggio. Non riesco a mangiare un'intera torta in un pomeriggio, quindi è necessario tagliarla per adattarla alla quantità che posso mangiare.
Quando Scrum è stato "inventato" per la prima volta, lo sprint predefinito era normalmente di 4 settimane.
In base a ciò che mi è stato detto, la ragione per questa lunghissima durata era semplicemente perché le persone in quel momento avevano difficoltà a immaginare di poter realizzare qualsiasi cosa con sprint più brevi.
Man mano che i team diventavano più fiduciosi con scrum, imparavano come suddividere meglio gli elementi del backlog in oggetti più piccoli di dimensioni più gestibili, e i team di sviluppo miglioravano non esagerando con il design iniziale, ma facendo abbastanza.
Oggi, credo che la maggior parte delle squadre considererebbero 4 settimane di durata molto lunga di sprint. Ho l'impressione che 2 settimane siano abbastanza normali. I team di XP eseguono solo 1 settimana di iterazioni e completano le storie utente complete in ogni iterazione.
Quindi è necessario essere più bravi a dividere gli elementi del backlog in oggetti più piccoli, ognuno dei quali dà un piccolo incremento nel valore aziendale al prodotto finale. È possibile, questo è stato dimostrato. (anche se non escludo 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 ciclo di feedback e migliorare nel trasformare piccole unità di lavoro in iterazioni più brevi. In questo modo c'è meno di andare male, meno che cambierà e meno complessità da gestire in un colpo solo.
Dividere le storie è spesso un'area problematica per le persone ma migliora con ciò che fai. Lavora a stretto contatto con il PO per capire se è possibile consegnarlo per fasi e fornire ancora valore nello sprint.
Ecco un grande poster che aiuta a dividere storie, è da un sito web chiamato agileforall.com e puoi trovare il poster qui, è davvero utile avere questo come affinare gli elementi del backlog:
Inoltre, è utile avere a disposizione la definizione di reso disponibile quando si raffina e si pianifica in modo da tenerlo a mente quando ci si impegna a completare qualcosa in uno sprint breve.
Leggi altre domande sui tag scrum
