Prioritizzazione e obiettivi a medio termine
In un altro articolo ho già scritto di come possiamo effettuare una prioritizzazione nella nostra vita privata attraverso "Adesso" e "Più tardi". Gli acquisti pianificati non vengono suddivisi in categorie come: cosa dobbiamo comprare? Cosa dovremmo comprare? Cosa potremmo comprare e cosa non compreremo affatto? Di seguito spiegherò come si può implementare facilmente la pianificazione con "Adesso" e "Più tardi" e come si può contemporaneamente lavorare verso una visione più ampia per il prodotto.
Una visione a medio termine per il prodotto (circa tre mesi) si è dimostrata piuttosto utile. All'inizio di un nuovo trimestre, il Product Owner dovrebbe fissare un obiettivo e dire: "Questo punto voglio averlo raggiunto in tre mesi." Questa definizione degli obiettivi viene fatta insieme al team e agli stakeholder. La visione definitiva di un prodotto, invece, spetta esclusivamente al Product Owner.
Il Product Owner non deve fissarsi troppo su questa visione – può anche essere modificata. Ma senza una chiara scadenza temporale, i temi urgenti che emergono poco prima degli Sprint Planning Meeting influenzerebbero rapidamente la prioritizzazione. Senza una visione chiara, i temi urgenti riceverebbero sempre più attenzione rispetto a quelli strategicamente importanti.
Quali fattori dovrei considerare?
Quando devo scegliere tra diverse idee per una visione a medio termine, preferisco procedere in modo formale, così da poter spiegare e giustificare la mia decisione. Si dovrebbe poter dire: "Ho deciso di concentrarmi su questo e quello, invece che su qualcos'altro" e poi presentare i fatti sulla base dei quali si è presa questa decisione.
Tuttavia, il Product Owner deve innanzitutto suddividere le User Stories all'inizio di ogni Sprint in "Adesso" o "Più tardi". Questo aiuta a decidere su quali item lavorare nel prossimo Sprint. Invece dell'approccio formale e ben spiegabile, il Product Owner dovrebbe consultare i seguenti quattro punti per ogni Product Backlog Item:
Quanto sarà prezioso il feature
L'effetto di apprendimento che si verificherà con questo feature
Il rischio di questo feature
Il costo del feature
Gli item vengono prima ordinati in base al punto 1, cioè in base al loro valore. Fino a qui è un metodo di prioritizzazione molto tradizionale. Tuttavia, questo Backlog appena ordinato viene poi riorganizzato in base ai punti 2-4. A seconda di quanta influenza esercitano questi fattori, si spostano i singoli feature verso l'alto. Ma prima spiego di cosa trattano questi fattori:
Il secondo fattore riguarda quanto grande sia l'effetto di apprendimento nello sviluppo di un determinato feature. Questo può significare, ad esempio, che si impara qualcosa sulla tecnologia utilizzata (qualcosa non è così semplice come si pensava) o si scopre come reagiscono gli utenti a una nuova interfaccia. Se quindi attraverso un determinato Backlog Item si può imparare qualcosa di importante, lo si sposta verso l'alto nel Product Backlog in modo che possa essere sviluppato nel prossimo Sprint.
Per quanto riguarda il rischio, preferisco sviluppare i feature più rischiosi prima piuttosto che dopo. In questo modo si può scoprire quali impatti ha questo rischio. Quindi anche questi item vengono messi nel prossimo Sprint. Tuttavia, se c'è la possibilità di evitare completamente un rischio (ad esempio eliminando del tutto il feature), l'item non viene inserito nel prossimo Sprint. Nel migliore dei casi, si può procedere così anche negli Sprint successivi, evitando completamente il rischio.
L'ultimo fattore riguarda i costi. Alcuni feature tendono ad essere più economici se vengono completati il prima possibile. Diventano sempre più costosi quanto più li si rimanda. Inserire questi item nel prossimo Sprint può mantenere bassi i costi.
Utilizza questi quattro fattori per la selezione degli item per i prossimi Sprint e crea una visione a medio termine (tre mesi). In questo modo potrai effettuare una buona prioritizzazione "Adesso" e "Più tardi" per raggiungere l'obiettivo complessivo.
