E' approccio comune, sia in Agile che Agile@Scale, priorizzare le User Story secondo quello che è il Valore associato, definito primariamente dal Product Owner con il Key-Stakeholder di riferimento.
Non sempre però questa scelta, in termini assoluti, è la più indicata, soprattutto se si considerano i seguenti fattori:
- Gestione del Rischio, annessa a particolari feauture o parti del sistema: si pensi ad una funzionalità che interessa un domino poco noto o all'adozione di una tecnologia sconosciuta o poco matura;
- Efficienza del Team, che può ridursi qualora le User Story a maggior priorità siano fortemente legate ad uno scope specifico (esempio, sviluppo della UI) e alcuni membri del Team non abbiano competenze sufficienti per dare un reale contributo.
Il primo fattore, in linea di massima, viene affrontato con degli Spike (funzionali o tecnologici) per confutare le proprie asserzioni. Nel caso dei framework @Scale (DAD e SAFe) si parla direttamente di approccio Risk-Driven, prevedendo di dare priorità allo sviluppo dei Work Item con alto rischio. Si consideri, ad esempio, una scelta architetturale che contempla la possibile adozione di un ESB, che, oltre ad essere esplicitata da Technical Story (livello Program se si adotta SAFe), può essere sottesa ad una User Story del tipo:
Essendo un Solution Architect voglio poter disporre degli strumenti per integrarmi con il resto della piattaforma con bassa dipendenza
Se tale User Story ha priorità bassa, potrei trovarmi nelle condizioni per cui una scelta architetturale fondamentale venga rinviata troppo nel tempo e le conseguenze, in caso di ipotesi errate e/o problemi relativi, crescano esponenzialmente. La soluzione è quella di "anticipare" tali User Story, affrontando subito problemi che altrimenti diventerebbero troppo costosi e creerebbero un debito tecnico molto alto. Utilizzando questo approccio, diamo allo Spike un "valore più nobile", sviluppando comunque un pezzo di sistema che poi sarà utile agli stakeholder perché realizzato confutando quanto ipotizzato o trovando la soluzione migliore.
Il secondo fattore è, invece, più ostico e meno contemplato nella letteratura Agile tipica. In teoria i membri del Team dovrebbero essere cross-functional e quindi poter operare indistintamente sulle varie parti del sistema che afferiscono alle User Story (tipicamente task). In pratica, una situazione di questo tipo è difficile da raggiungere e i membri del Team tendono a specializzarsi comunque rispetto ad un aspetto ben specifico. Bisogna allora evitare che nella scelta del Backlog di Iterazione le User Story afferiscano tutte alla stessa area, in modo da impiegare efficacemente il Team, cosa che rappresenta un Valore trasversale al progetto.
In pratica, possiamo definire un Iteration Value, composto da:
User Stories Value + Risk Value + Team Engagement
che, bilanciando equamente le tre componenti portanti, permette di:
- ottenere un ampio Valore del delivery di iterazione;
- abbattere velocemente il rischio di determinante scelte;
- rendere il Team efficiente.
Per tener traccia di tale informazione è utile specificare esplicitamente la scelta di inserire nel Backlog di Iterazione una (o più) User Story con priorità inferiore, riportando una semplice descrizione preceduta dal "tipo di valore" che si massimizza.
Iteration Value
