Fare stime è difficile. Per gli sviluppatori di software, è uno degli aspetti più difficili, se non il più difficile, del lavoro. È necessario tenere conto di una serie di fattori che aiutano gli owner di prodotto a prendere decisioni che riguardano l'intero team e l'azienda. Con tutti questi elementi in gioco, non c'è da meravigliarsi che tutti, dagli sviluppatori ai dirigenti superiori, siano inclini a perdere quasi subito la pazienza. Ma questo è un errore. La stima degli Story Point Agile è proprio questo: una stima. Non è un giuramento di sangue.
Non è necessario lavorare nei fine settimana per compensare il fatto di aver sottovalutato un lavoro. Detto questo, esaminiamo alcuni modi per rendere le stime Agile il più accurate possibile.
Collaborazione con l'owner di prodotto
Nello sviluppo Agile, l'owner di prodotto ha il compito di dare priorità al backlog, l'elenco ordinato del lavoro che contiene brevi descrizioni di tutte le funzioni e le correzioni desiderate per un prodotto. Gli owner di prodotto acquisiscono i requisiti dell'azienda, ma non sempre comprendono i dettagli dell'implementazione. Quindi una buona stima può fornire all'owner di prodotto nuove informazioni approfondite sul livello di lavoro richiesto per ciascun elemento, che quindi si ricollega alla valutazione della priorità relativa per ciascun elemento.
Quando il team di progettazione avvia il processo di stima, di solito sorgono domande sui requisiti e sulle storie utente. E questo è un bene: queste domande aiutano l'intero team a comprendere meglio il lavoro. Per gli owner di prodotto in particolare, suddividere gli elementi di lavoro in porzioni granulari e stime tramite gli Story Point li aiuta a dare priorità a tutte le aree di lavoro (e potenzialmente anche a quelle nascoste!). Una volta che ha ricevuto le stime dal team di sviluppo, non è raro che l'owner di prodotto riordini gli elementi nel backlog.
La stima degli Story Point Agile è uno sport di squadra
Coinvolgere tutti i membri del team (sviluppatori, designer, tester, responsabili dell'implementazione... in una parola tutti) è fondamentale. Ogni membro del team porta una prospettiva diversa sul prodotto e sul lavoro necessario per portare a termine una storia utente. Ad esempio, se il team di gestione del prodotto vuole fare qualcosa all'apparenza semplice, come il supporto di un nuovo browser web, i team di sviluppo e controllo di qualità devono intervenire perché, grazie alla loro esperienza, sanno quali insidie potrebbero essere in agguato sotto la superficie.
Allo stesso modo, le modifiche del design richiedono non solo il contributo del team di design, ma anche quello dei team di sviluppo e del controllo di qualità. Se parte del team di prodotto viene lasciata fuori dal processo di stima, risulteranno stime di qualità inferiore, il morale sarà basso perché i collaboratori chiave non si sentono inclusi e la qualità del software ne risulterà compromessa.
Quindi, non lasciare che il tuo team diventi vittima di stime che ricadono nel vuoto. È una strada che li porterà sicuramente al fallimento!
Vuoi provare gli Story Point? Innanzitutto, registrati o accedi a Jira
Confronto tra Story Point e ore
I team software tradizionali forniscono stime in formato temporale: giorni, settimane, mesi. Molti team Agile, tuttavia, sono passati agli Story Point. Gli Story Point sono unità di misura per esprimere una stima del lavoro complessivo richiesto per implementare completamente un elemento del backlog di prodotto o qualsiasi altra porzione di lavoro. I team assegnano gli Story Point in relazione alla complessità e alla quantità di lavoro e al rischio o all'incertezza. I valori vengono assegnati per suddividere in modo più efficace il lavoro in porzioni più piccole, in modo da poter affrontare gli aspetti più incerti. Nel tempo, questo aiuta i team a capire quanto possono ottenere in un periodo di tempo e crea consenso e coinvolgimento verso la soluzione. Può sembrare controintuitivo, ma questa astrazione è effettivamente utile perché spinge il team a prendere decisioni più dure sulla difficoltà del lavoro. Ecco alcuni motivi per utilizzare gli Story Point:
- Le date non tengono conto del lavoro non correlato al progetto che inevitabilmente si insinua nelle giornate lavorative: e-mail, riunioni e colloqui in cui i membri del team potrebbero essere coinvolti.
- Le date portano con sé un significato emotivo. Le stime relative eliminano questo risvolto emozionale.
- Ogni team stimerà il lavoro su una scala leggermente diversa, il che significa che la loro velocity (misurata in punti) sarà naturalmente diversa. Questo, a sua volta, rende impossibile fare politica usando la velocity come arma.
- Una volta concordato lo sforzo relativo di ciascun valore in Story Point, puoi assegnare i punti rapidamente e senza troppe discussioni.
- Gli Story Point premiano i membri del team per la risoluzione dei problemi in base alla difficoltà, non al tempo impiegato. In questo modo, i membri del team restano concentrati sul valore del rilascio, non sul tempo impiegato.
Purtroppo, gli Story Point vengono spesso utilizzati in modo improprio. Gli Story Point hanno esito negativo quando vengono utilizzati per giudicare le persone, assegnare timeline e risorse dettagliate e quando vengono scambiati per una misura della produttività. Invece, i team dovrebbero utilizzare gli Story Point per comprendere la dimensione del lavoro e la definizione delle priorità di quest'ultimo. Per una discussione approfondita sugli Story Point e sulle pratiche di stima, dai un'occhiata a questa tavola rotonda con esperti del settore e continua a leggere per suggerimenti di stima Agile.
Story Point e Planning Poker
I team che iniziano con gli Story Point usano un esercizio chiamato Planning Poker. In Atlassian, il Planning Poker è una pratica comune in tutta l'azienda. Il team prende un elemento dal backlog, ne discute brevemente e ogni membro formula mentalmente una stima. Quindi, tutti tengono in mano una scheda su cui hanno annotato la propria stima. Se tutti sono d'accordo, ottimo! In caso contrario, prenditi del tempo (ma non troppo, solo un paio di minuti) per capire la logica alla base delle diverse stime. Ricorda però che la stima dovrebbe essere un'attività di alto livello. Se il team si è addentrato troppo nei dettagli, fai un respiro e cerca di portare la discussione su un livello generale.
Pronto a provare?
- Installa questa app di Planning Poker
- Scopri di più su Planning Poker
Crea stime più intelligenti, senza affaticarti troppo
Nessun task individuale dovrebbe superare le 16 ore di lavoro (se utilizzi gli Story Point, potresti stabilire, ad esempio, un limite massimo di 20 punti). È semplicemente troppo difficile stimare con un alto grado di sicurezza i singoli elementi di lavoro più grandi di questi. E questa sicurezza è particolarmente importante per gli elementi in cima al backlog. Quando un elemento viene stimato al di sopra della soglia di 16 ore (o 20 punti) del team, è un segnale che indica di suddividerlo in porzioni più granulari e di ripetere la stima.
Per gli articoli che si trovano nei livelli più profondi del backlog, fornisci una stima approssimativa. Nel momento in cui il team inizierà effettivamente a lavorare su questi elementi, i requisiti potrebbero cambiare e la tua applicazione sarà sicuramente cambiata. Quindi le stime precedenti non saranno così accurate. Non perdere tempo a stimare il lavoro che probabilmente cambierà. Basta dare all'owner di prodotto una cifra approssimativa che può utilizzare per dare priorità alla roadmap del prodotto in modo appropriato.
Impara dalle stime precedenti
Durante le retrospettive, il team può incorporare gli approfondimenti ricavati dalle iterazioni passate, inclusa l'accuratezza delle stime. Molti strumenti Agile (come Jira) tengono traccia degli Story Point, il che rende molto più facile riflettere e ricalibrare le stime. Prova, ad esempio, a recuperare le ultime 5 storie utente che il team ha completato con il valore 8 di Story Point. Discuti insieme al team se ciascuno di questi elementi di lavoro abbia richiesto un livello di impegno simile. Se la risposta è no, esaminate il motivo. Usa queste informazioni approfondite nelle future discussioni sulle stime.
Come con ogni altro aspetto dell'approccio Agile, le stime richiedono pratica. Con il tempo migliorerai sempre di più.
Risorse correlate
