La suddivisione degli Epic
Uno Scrum Trainer mi ha chiesto di recente qualche buon esempio di come grandi User Story (Epic) vengano suddivise in Story più piccole. Vorrei condividere questi esempi con te.
Epic 1: Trovare la giusta campagna di marketing
Il primo esempio riguarda un'azienda che vende software a grandi catene di distribuzione (WalMart ecc.). Il responsabile del reparto marketing doveva decidere come spendere il budget pubblicitario. Pertanto, la User Story (Epic) è stata scritta dalla sua prospettiva. Il suo primo grande obiettivo era:
Come responsabile del reparto marketing, vorrei poter visualizzare le campagne pubblicitarie passate, in modo da poter identificare e ripetere le campagne più redditizie.
I membri del team dissero che si trattava chiaramente di un Epic. Così chiesi loro di ricavarne diverse Story più piccole:
1a: Come responsabile del reparto marketing, vorrei poter selezionare un periodo di tempo da cui provengono le campagne pubblicitarie da verificare, in modo da...
2a: Come responsabile del reparto marketing, vorrei poter scegliere quali campagne (volantini, TV, e-mail, radio ecc.) includere nella verifica, in modo da...
(Nota che ho numerato le Story in modo che si possa riconoscere da quale Story originale derivano. In un progetto reale non lo farei necessariamente, a meno che non abbia un tool che lo faccia automaticamente.)
Non sapevo esattamente quanto fossero grandi queste due Story e se dovessero essere ulteriormente suddivise. Così chiesi al team: "Se doveste stimare queste Story, quale unità vi verrebbe in mente per prima? Ore, giorni, settimane, mesi o anni?" Per la 1a erano giorni, quindi la Story rimase così com'era. Per la 1b erano settimane, perciò suddividemmo la Story ulteriormente:
1b1: Come responsabile del reparto marketing, vorrei poter visualizzare le informazioni sui volantini delle campagne precedenti, in modo da...
1b2: Come responsabile del reparto marketing, vorrei poter visualizzare le informazioni sulla pubblicità TV delle campagne precedenti, in modo da...
1b3: Come responsabile del reparto marketing, vorrei poter visualizzare le informazioni sulla pubblicità via e-mail delle campagne precedenti, in modo da...
ecc.
Ognuna di queste Story aveva una buona dimensione ("stimeremmo questa Story in giorni"). Tuttavia, necessitavano ancora di certe informazioni – le cosiddette "Conditions of Satisfaction", che sono essenzialmente test di accettazione ad alto livello. Per la 1b2, i membri del team scrissero sul retro del cartoncino:
Quanti spettatori di quale fascia d'età c'erano?
Quanti spettatori di quale fascia di reddito c'erano?
Esempio 2: Massimizzazione del fatturato di un hotel
In questo esempio si tratta di un hotel il cui fatturato doveva essere massimizzato, cioè il gestore voleva trovare il prezzo più alto possibile per le camere. I prezzi venivano calcolati in base a diversi fattori, come i prezzi delle camere di hotel comparabili, la stagione, grandi eventi nelle vicinanze (quando il Super Bowl o un campionato mondiale viene organizzato in una città, lì i prezzi salgono) ecc.
Questa era la User Story originale (Epic):
1: Come albergatore, vorrei trovare il prezzo ottimale per le mie camere d'albergo.
Per semplicità, supponiamo che l'hotel disponga di una sola categoria di camere. Come già detto, molti fattori possono influenzare il prezzo di una camera d'albergo. La formula base per il calcolo del prezzo della camera è:
Prezzo camera = f (a,b,c...)
Questa funzione è soggetta a diversi fattori. Per ognuno di essi c'è una Story:
1a: Come albergatore, vorrei determinare il prezzo ottimale per le mie camere in base ai prezzi dell'anno scorso.
1b: Come albergatore, vorrei determinare il prezzo ottimale per le mie camere in base ai prezzi di hotel comparabili.
La Story 1a dice solo che i prezzi dell'anno precedente vengono considerati nella funzione. La Story 1b dice che anche i prezzi che altri hotel applicano vengono inclusi nel calcolo.
Ognuna delle Story era piuttosto grande (un Epic) e naturalmente c'erano più delle due Story sopra menzionate. Sarebbe stato quindi impossibile inserirle tutte in un unico Sprint. Le Story vennero implementate gradualmente e così la formula in questione produceva un prezzo sbagliato, poiché veniva costruita nel seguente modo:
Prezzo camera = f (a)
poi
Prezzo camera = f (a,b)
poi
Prezzo camera = f (a,b,c)
ecc.
Dopo il primo Sprint, il calcolo sarebbe stato Prezzo camera = f (a) e si sarebbe ottenuto un prezzo sbagliato (che non può essere comunicato al cliente). Il calcolo in sé, però, è fondamentalmente corretto. Forse i valori per (b) e (c) sono codificati in modo fisso o vengono semplicemente ignorati. Ma in questo modo, algoritmi così complessi possono essere costruiti in modo incrementale.
Poiché la Story 1b era ancora troppo grande, venne ulteriormente suddivisa:
- 1b1: Come albergatore, posso definire un certo numero di hotel comparabili. (Per questo fu usato il termine "Comparable Set" in questa azienda.)
- 1b2: Come albergatore, posso aggiungere hotel al Comparable Set.
- 1b3: Come albergatore, posso rimuovere hotel dal Comparable Set.
- 1b4: Come albergatore, posso eliminare un intero Comparable Set che non mi serve più.
- 1b5: Come albergatore, mi oriento ai prezzi delle camere degli hotel in un determinato Comparable Set per stabilire i miei prezzi.
Ecco due Story aggiuntive:
- 1c: Come albergatore, vorrei adeguare il prezzo ottimale per le mie camere all'occupazione prevista.
- 1d: Come albergatore, posso definire parametri che influenzano il prezzo ottimale, come l'occupazione desiderata, l'occupazione minima e l'occupazione massima (potrebbe superare il 100%).
Conclusione sulla suddivisione degli Epic
Quasi tutti i team hanno inizialmente difficoltà a suddividere correttamente le User Story. Per esperienza, a un certo punto entro il primo anno scatta un "clic" e i membri del team capiscono come suddividere le Story specificamente per il loro settore e i loro progetti. Se non hai ancora molta familiarità con Agile o le User Story, non mollare – con il tempo diventerà più facile!