Aprile 12, 2021 - di Giulia Tumminelli
Estimation in Agile Scrum: cosa è, consigli ed esempi pratici
In questo articolo affronteremo il tema della estimation in Agile Scrum. Ci concentreremo su cos’è e come affrontare questa attività senza problemi con consigli ed esempi pratici.
Ecco cosa troverete nell’articolo:
- Cos’è il concetto di “estimation” in Agile Scrum?
- Perché la maggior parte delle stime sono destinate a fallire? Perché farle allora?
- Best practice nella Estimation in Agile Scrum
- Quali trappole evitare nella Estimation in Agile Scrum?
Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 100 pagine su Agile, Team Cross-funzionale, Scrum/Kanban, Backlog, etc. ti presento Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.
Per capire quali sono le best practice nella estimation in Agile Scrum, soffermiamoci sui nostri amati stakeholder e su cosa accade solitamente quando ci sono nuovi prodotti da lanciare o progetti importanti da inserire in roadmap.
Vi è mai capitato di avere stakeholder col fiato sul collo che richiedono un’ETA (expected time of arrival) per il completamento di un prodotto?
E di chiedere al team quale fosse il tempo di completamento di un prodotto e sentirvi dire dal vostro tech lead: relax… in due settimane sarà tutto pronto, per poi ritrovarvi alla fine delle fatidiche due settimane con la casa in fiamme?
Bene! Benvenuto nel club dei Product Manager che hanno l’ansia di avere l’ansia e che non riescono a dormire la notte perché la parola ETA e relax fanno a pugni nel loro cervello vita natural durante 😀
La parola magica per risolvere in parte questo conflitto interiore è “Estimation”. Ora… se siete dei PM, sapete benissimo che ci saranno sempre onde gigantesche da affrontare e che la soluzione migliore per superare i conflitti (anche interiori) è imparare a surfarci sopra.
E l’estimation è proprio questo: un mezzo per surfare sopra alle incertezze. Non è perfetto e non è bulletproof (potrai sempre cadere dalla tavola), ma è una questione di esercizio costante e instancabile per rimanere in piedi.
Cos’è il concetto di “estimation” in Agile Scrum?
Le definizioni non sono sicuramente l’unico punto su cui bisogna focalizzarsi quando si parla di cosa fare e non fare nella estimation, ma sono un buon punto di partenza da cui iniziare.
In Scrum, l’estimation è l’attività di mettere una stima in termini di “story points” (misura relativa della dimensione e complessità di una user story) alle cosiddette user story durante il backlog refinement o lo Sprint Planning. Questa attività viene fatta solitamente con il metodo “Planning Poker” in Agile Scrum, di cui abbiamo parlato più approfonditamente qui.
Perché la maggior parte delle stime sono destinate a fallire? Perché farle allora?
Sembra un concetto controintuitivo ma è la pura verità. Specialmente all’inizio, quando il team non ha “l’occhio”, il “metro di misura” allenato per fare delle stime accurate, l’attività di estimation sarà destinata a fallire.
Allora perché si stima? Perché “perseverare nell’errore”?
Per due motivi:
Non è importante la meta finale ma il cammino!
Quali sono i ragionamenti che portano a stimare quella user story come 1, 2, 3 story point e via dicendo?
In sostanza, non importa se la stima di una user story o di un bug alla fine dello Sprint è incorretta. Quello che importa in assoluto è lo sforzo che il team fa, Sprint dopo Sprint, per avvicinarsi alla più corretta stima possibile e la discussione che si genera durante il backlog refinement.
E qui aggiungo un piccolo approfondimento dato dalla nostra PM Giulia Nidasio:
“Il vero valore della estimation sta nel disincagliare le conversazioni tra il team e portare alla luce le azioni che si danno (ahimé) per scontato: the devil is in the details! Quando un team member vota 2 e l’altro 8, lì si entra nel vivo della conversazione e salgono in superficie tutte le sfumature”.
“Practice makes perfect”
Sprint dopo Sprint il team diventerà sempre più esperto e affinerà il “metro di misura” per stimare le user story.
Ma quindi “come si migliora?”
Sicuramente con tanta tanta pratica, ma ho chiesto consiglio ai miei fellow PM e ho preso a cuore un prezioso tip (secondo me mind blowing!) datomi da Giulia Nidasio:
“Un esercizio che a me è sempre risultato utile è quello di tenere un estimation dictionary, creato e retroalimentato dal team. Come funzionerebbe? Sarebbe una semplice trello board in cui si aggiungono a poco a poco le User story con le loro stime. Ogni mese si fa un upgrade delle user story, così da avere tanti esempi catalogati secondo le varie estimation/t-shirt size a cui fare riferimento.”
Adesso che abbiamo sviscerato un po’ meglio il motivo per cui è fondamentale allenare il “metro di misura” del team di Prodotto, passiamo al “cosa fare”, quali sono gli strumenti che potete utilizzare per affinare l’arte delle estimation.
Best practice nella Estimation in Agile Scrum
Product team maturi vs Product team giovani
Qui bisogna fare una piccola differenza tra team maturi e giovani.
Se il team che avete di fronte è un team navigato, sicuramente non ci sarà alcun bisogno di stabilire un punto di partenza, ovvero di capire qual è la cosa più piccola che hanno mai fatto. Solitamente questa è la fatidica “label change”, ovvero cambio di etichetta che viene spesso identificata come lo sforzo più piccolo che un team può fare.
Un team prodotto maturo ne avrà già viste di cotte e di crude, ciò non toglie che ogni tanto serva una sorta di ricalibramento per capire se si stanno facendo degli errori di valutazione nello stimare le storie o il team sta ancora percorrendo la strada giusta.
Per un team appena formato, le cose cambiano e come… Perché il team probabilmente proviene da background e aziende diverse ed è lì che lo sforzo più grande deve avvenire. Qui è necessario stabilire un punto di partenza per le stime, un punto fermo: il famoso cambio di etichetta come dicevo prima, per poi, a cascata, essere in grado di stimare tutto il resto.
E come si stabilisce il punto di partenza? Con il t-shirt sizing.
T-shirt sizing
Sicuramente esistono milioni e milioni di metodologie diverse in Agile Scrum per stimare le user story, ma nessuna può considerarsi universale per tutti.
Quello che ho trovato più semplice da implementare e da tenere come riferimento in questi anni è la t-shirt sizing.
Come funziona?
Chiedi al team di pensare alla cosa più piccola che abbiano mai implementato. Come dicevo prima… un cambio di etichetta, il testing di una feature molto semplice… Insomma, la cosa più piccola in termini di sviluppo con la quale si sono confrontati nella loro carriera da programmatori: sono sicura che d’idee non ne mancheranno.
Una volta stabilito il punto di partenza, ovvero la nostra S, la t-shirt più piccola di tutte, andiamo ad incrementare la size con feature/task sempre più grossi e facciamo sempre una comparazione con la taglia precedente.
Quando si è riusciti a fare degli esempi concreti per ogni taglia è qui che il divertimento inizia. Lo chiamo “re-shuffling”. Divertitevi a prendere ad esempio diverse storie completate in passato e ad assegnargli una size, vedrete che man mano il team si farà le idee più chiare sulla definizione di S, M, L e così via.
Per avere un’idea orientativa sulla quale basarsi quando si approccia la tematica del t-shirt sizing, ecco degli esempi:
- Small = 1, 2, 3 story point
- Medium = 5, 8 story point
Adesso tiriamo una linea e vi spiego il perché!
Se una storia è Large o Extra Large: 13, 20 story point, significa che è molto complessa e che bisogna scomporla in pezzetti ancora più piccoli.
Di solito, i Product team più navigati si fermano a 13 story point: il magic number. Quando una storia è stimata come 13, probabilmente bisognerà fare uno sforzo in più e dividerla ulteriormente per evitare di portarsela a presso da uno Sprint all’altro.
Finalmente, quando l’attività di t-shirt sizing è finita, è qui che inizia l’allenamento vero e proprio durante ogni sessione di backlog refinement.
Cosa può aiutare il team a stimare nella maniera più accurata possibile?
A mio parere, tenere in considerazione i seguenti fattori:
- Complessità della storia (quanto è effettivamente complessa la storia di riferimento?)
- Dipendenza dagli altri team (ci saranno per caso momenti di back and forth tra team diversi per il completamento della storia?)
- Definition of Done (quali sono gli step necessari per portare la storia a completamento?)
- Quanto tempo sarà impiegato? (Quel determinato task è in genere “time consuming” o no?)
Tutti questi fattori sono cruciali per ottenere delle stime sempre più accurate e “concrete”, ma come ho detto prima “only practice makes perfect”, perciò non bisogna avere fretta ma provare e riprovare e riprovare ancora.
Fin qui abbiamo parlato delle best practice. Adesso, ci concentreremo sui pitfall, sulle trappole dietro l’angolo, sul “cosa non fare” per evitare gli errori che si commettono di solito quando si inizia questo percorso.
Quali trappole evitare nella Estimation in Agile Scrum?
Come al solito in Product Heroes ci piace parlare di esperienze vissute e di ginocchia sbucciate.
Vi racconterò due trappole nella quale spesso si cade con le tecniche di estimation, così che avrete un punto di riferimento per evitarle in futuro.
Trap #1: Accontentarsi di una “stima orientativa” senza aver scavato a fondo col tech team
Vi tenterà l’idea, e come se vi tenterà l’idea, di accontentarvi di una stima orientativa... specialmente se il “Business” vi sta col fiato sul collo, giorno e sera, per averla e il tech team si rifiuta di darne una accurata.
In passato, mi è successo diverse volte di credere alla “prima stima” data dal team tech. Non fermatevi lì, ma continuate a scavare.
Fate le seguenti domande:
- Quali sono le macro-fasi necessarie per portare a casa la storia?
- Non sarebbe il caso di aggiungere un buffer per ogni evenienza?
- Quali sono i rischi associati alla storia?
Una volta chiarite queste domande, sicuramente il tech team sarà in grado di dare una estimation molto più vicina alla realtà e meno “fantasiosa”.
Trap #2: Il PM suggerisce stime a caso al team “because he knows better”
Ma cosa vuoi che sia? Sarà una cosa da due settimane al massimo… Fai questo, metti questo, e “Frankenstein” è pronto per la “delivery” della storia. Questa è la ricetta più pericolosa che ci sia.
E sapete perché? Perché nel processo decisionale il team non è stato l’attore principale, ma uno spettatore passivo. E non c’è nulla di peggio che creare una situazione in cui tutte le discussioni relative ai possibili rischi, alle dipendenze, alla complessità del prodotto sono accadute solo nella mente del PM (probabilmente tecnico che ne sa un po’ di programmazione) senza l’intervento di un team che in teoria dovrebbe essere “empowered”.
Esattamente è come dare al team la soluzione e non il problema da risolvere. Qui non c’è nessun “shared understanding”, nessun “consensus”, nessun “cammino”, nessun “ragionamento”.
E non è proprio questo il ragionamento, lo shared understanding, il cammino che fa di un gruppo di persone un team?
Per fare un breve recap di quello di cui abbiamo parlato in questo articolo:
- Molte stime sono destinate a fallire, ma non per questo bisogna mollare la presa perché stimare le user story ha un valore che va al di là della stima in sé e che crea quello “shared understanding” che un team di prodotto dovrebbe avere.
- Practice makes perfect! La pratica nelle estimation è tutto. Più si fa pratica, più si diventa bravi.
- Attenzione alle trappole dietro l’angolo. L’estimation è un’attività di gruppo e conviene non fermarsi al first round ma dive deep per raggiungere delle stime più precise.
Spero che questo excursus sulla estimation in Agile Scrum vi sia stato d’aiuto e che gli strumenti suggeriti in questo articolo vi servano come punto di partenza per imparare a surfare nel mare delle incertezze che sono le estimation.
One reply on “Estimation in Agile Scrum: cosa è, consigli ed esempi pratici”
Andrea
Utilissimo! E quando le storie si stimano in ore per temi di budget, che approccio suggerisci?