Guesstimating multiple Epics

Il punto dell'esercitazione è molto simile al fatto che i Product Manager desiderano avere un'idea delle funzionalità che possono aspettarsi nella prossima versione.

Molto probabilmente, anche gli epici non saranno tutti della stessa dimensione.
Supponiamo che il team possa, in base alla velocità attuale, gestire 30 punti memoria fino alla data di rilascio. Supponiamo anche che le ipotesi si presentino a:

• Epic A 20 SP,
• Epic B 10 SP,
• Epic C: 8 SP,
• Epico D: 8 SP.

Se lavori su quei poemi epici nell'ordine dato (A - > B - > C - > D), allora potresti finire i primi due, se le tue ipotesi non sono troppo lontane dalla realtà.
D'altra parte, i Product Manager possono usare queste informazioni per dare la priorità alle epopee e fare Epic A per ultime. In questo modo sarai in grado di finire tre di loro con un po 'di flessibilità per contrastare l'incertezza nelle ipotesi.

Idealmente se hai qualcosa che è stato stimato essere un poema epico sulla stima iniziale, allora dovresti tenere una discussione separata su come meglio scomporla in storie più gestibili e stimarne ognuna di quelle, e farlo per ogni epico o almeno i due più importanti. Gli stessi Epics non dovrebbero mai essere parte di uno sprint, se qualcosa con uno stack elevato è considerato un epico, il grooming dovrebbe mirare a scomporre quell'epica. Ciò consente di assegnare priorità a tutte le storie appena create in modo che tutto il lavoro più importante abbia le migliori possibilità di essere fatto. Alla scadenza può accadere che nessuno degli epici sia effettivamente realizzato al 100%, ma tutti i pezzi importanti di ogni epica sono fatti. Ciò dovrebbe comportare clienti più felici, perché una macchina di base è molto meglio di un'auto con tutti i campanelli e fischietti, ma non ha ancora le ruote.