Pianificare una release di prodotto
“Quando rilasciamo?” Ecco la domanda con la quale convivono da sempre i Project Manager e la stragrande maggioranza dei Product Manager.
Anche lavorando in Scrum questa è domanda ricorrente per i Product Owner.
I progetti inseriti in roadmap hanno un orizzonte temporale che può variare dai 3 ai 6 mesi e necessitano di una pianificazione accurata.
Diciamo allora che è necessario pianificare a livello di release per avere una stima della data di rilascio.
Per fare questo dovremo innanzi tutto stimare la dimensione del progetto da portare a termine (il size di tutte le user stories) e poi fare riferimento alla velocity del team.
Un’altra raccomandazione utile è esprimere la data di rilascio mediante un range di date (dopotutto si tratta di una stima, non di un calcolo matematico!).
Le situazioni che si possono presentare pianificando una release possono essere variegate, a seconda del tipo di mercato in cui è attiva l’azienda, il tipo di contratti utilizzati e l’organizzazione interna delle risorse.
Vediamo alcuni dei casi più frequenti.
Progetto interno, senza vincoli forti su date
Diciamo che il team ha già lavorato su altri progetti.
E’ questo il caso più semplice per effettuare delle stime.
Se il team è già struttuato e lavora su un domino noto con tecnologie conosciute abbiamo confidenza nel fatto che la velocity pregressa sia un buon indicatore del comportamento futuro.
Prendiamo le velocity degli ultimi 6 sprint (o più se sono disponibili ulteriori dati), eliminiamo il valore massimo ed il minimo e facciamo una media delle restanti velocity. Questo è il riferimento per la nostra stima.
Ricordate l’idea di esprimere la stima in un range? Teniamo conto del valore più alto e più basso che rimangono dopo la sottrazione iniziale.
Esempio:
- il team negli ultimi 8 sprint ha avuto la seguente velocity:
20 + 25 + 31 + 29 + 18 + 34 + 30 + 38 - eliminiamo i valori 20 e 38 (il più basso ed il più alto)
- prendiamo 34 come valore superiore e 25 come valore inferiore
- se il backlog vale 150 story point in totale il progetto sarà terminato in un periodo che varia da 4,4 sprint (nel migliore dei casi) a 6 (nel peggiore).
Per molti un intervallo così ampio non è un’informazione utile… né comunicabile agli stakeholder.
In questo caso vi suggerisco di usare il buon senso.
Comunicare una durata di 4 sprint e mezzo significa non lasciare respiro al team e non prevedere alcun intoppo o contingenza (ferie, malattia, formazione, ecc.). Sei sprint potrebbero tuttavia risultare poco “digeribili” dai committenti.
Se mi trovassi in una situazione di questo tipo punterei su 5 sprint sapendo sin dall’inizio che alcune funzionalità potrebbero essere oggetto di descoping.
Progetto con data di rilascio fissa
In questo caso il vincolo è dato dal timing, quindi sarà lo scope di progetto a rappresentare la variabile.
Il team parte col chiedersi: “Quante iterazioni abbiamo da qui al rilascio?”
Esempio:
- la data ultima di rilascio è fissata per il 1° giugno (oggi è il 15 marzo)
- il team lavora con sprint di 2 settimane
- le velocity nelle iterazioni precedenti sono: 20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
- eliminiamo – come prima – i valori 20 e 38 (il più basso ed il più alto)
- prendiamo 34 come valore superiore e 25 come valore inferiore
- se il backlog di progetto vale complessivamente 150 story point per la data del primo giugno (5 sprint) saranno completati da un minimo di 125 ad un massimo di 170 story points.
Abbiamo quindi una buona confidenza che il progetto completo di tutte le sue funzionalità possa essere terminato per la data prevista.
O, per la precisione, garantiamo che 125 story points saranno completati per la data concordata e che i restanti 25 hanno buona probabilità di esserlo.
… ma attenzione! Potrebbero presentarsi casi in cui il calcolo evidenzi sin dall’inizio l’impossibilità di terminare per la data concordata.
Progetto con ambito fisso
Abbiamo un “capitolato” vincolante, è quindi la variabile tempo che può cambiare. Il team si chiede “Quanto tempo ci mettiamo a completare tutto?”
Esempio:
- dobbiamo necessariamente realizzare un progetto di 150 story points
- le velocity precedenti: 20 + 25 + 31 + 29 + 18 + 34 + 30 + 38
- eliminiamo i soliti valori 20 e 38
- prendiamo 34 come riferimento superiore e 25 come inferiore
- il progetto sarà terminato in un periodo che varia da 4,4 sprint (nel migliore dei casi) a 6 (nel peggiore).
In questo caso dato che lo scope è fisso per contratto comunicheremo che il progetto terminerà al più tardi in 12 settimane (6 iterazioni), ma prevediamo che possa anche essere chiuso prima (ad esempio nel corso dell’undicesima o della decima settimana).
Per chi fosse interessato ad approfondire il tema della pianificazione delle release sul sito di Mike Cohn sono disponibili diversi video sull’argomento.