Come affrontare le stime di progetti software in Scrum con gli Story Point – Parte 1

Quello delle stime è uno dei principali problemi nello sviluppo di progetti software su misura, ed è un problema ad oggi non ancora del tutto risolto.

Ci sono però vari modi per affrontare le stime e ridurre il rischio, uno di questi quando si lavora con processi di sviluppo ad iterazioni come Scrum e/o utilizzando le User Stories è quello degli Story Point.

In questa prima puntata in due parti del podcast spiego come si utilizza questo metodo nel migliore dei modi.

Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.

Trascrizione

Ciao da Alex Pagnoni e benvenuto nel CTOP Podcast, il podcast dedicato ai CTO e ai responsabili dei team di sviluppo, a chi vorrebbe diventarlo e a Founder e imprenditori digitali.

Nella precedente puntata ho accennato al fatto che avrei parlato delle stime nello sviluppo software e ho anticipato che sicuramente ci sarebbero voluti vari episodi per sviscerare per bene l’argomento.

Infatti quello delle stime è un tema molto ampio e delicato, che spazia dalla necessità per le funzioni business di sapere quando una certa funzionalità o un intero prodotto software sarà disponibile e di conseguenza di avere stime spesso puntuali e precise, al suo opposto che è quello di movimenti come quello del #NoEstimates dove si cerca di evitare del tutto la necessità di effettuare delle stime.

Su Twitter infatti si possono trovare migliaia di tweet con il tag #NoEstimates dove si spiega il grande spreco di tempo che si produce nel generare stime, un po’ l’analogo dell’utilizzare il GANTT per gestire progetti in ambito di sviluppo software.

Nell’episodio di oggi e in quello della prossima settimana non parlerò degli aspetti più filosofici della questione delle stime, mi concentrerò invece su un’applicazione specifica che è quella delle stime formulate in Story Point per quei team di sviluppo che come metodo di gestione del processo di sviluppo utilizzano Scrum e che in fase di Sprint Planning devono stimare il contenuto dello Sprint, spesso in forma di User Stories.

Tratterò di Scrum più in generale in altre puntate, in questo caso darò per scontato che tu sappia già cos’è Scrum e che tu stia valutando di implementarlo nella tua azienda o che sia già il metodo in uso attualmente.

In realtà anche per chi non usa esattamente Scrum o comunque lavora ad iterazioni, quello che spiegherò in questo puntata è comunque utile perché andrò a toccare vari argomenti che sono validi in assoluto come ad esempio quello del cono di incertezza.

Quindi ti invito ad ascoltare questa puntata e la successiva anche se non usi o non ti piace Scrum ma comunque ti ritrovi a dover gestire o effettuare stime nell’ambito dello sviluppo di software custom.

In ogni caso, quando si cerca di lavorare in modalità agile è facile trovare un’infinità di argomenti sul perché questo è l’approccio ottimale, infatti ormai da tanti anni non si discute più di agile come alternativa, ma almeno nell’ambito del digitale è un dato di fatto in buona parte delle realtà che lavorano in modo moderno.

Anzi si può dire per molti versi che lo stesso movimento agile è quasi “vecchio”, e in un certo senso superato da nuovi concetti, ma anche di questo conviene parlarne in una puntata dedicata.

A questa facilità nel trovare argomenti sulla bontà di Scrum o dell’agile corrisponde però una maggiore difficoltà nel trovare delle spiegazioni chiare e passo passo sugli strumenti e i processi di cui si ha bisogno per far funzionare queste metodologie al meglio.

E in questo episodio cercherò proprio di rendere la cosa più facile rispondendo alla domanda di come si stimano gli Story Point in un progetto di tipo agile come Scrum.

Innanzitutto, il contesto è che formuliamo delle stime in Story Point per darci un’idea di massima anche grezza su quando saremo pronti a consegnare una certa parte del nostro lavoro.

In Axelerant siamo sempre interessati ad avere in questo senso la migliore comprensione possibile e al più presto in modo da poter prendere decisioni e compromessi informati prima che sia troppo tardi.

Facciamo quindi del nostro meglio per capire quanto lavoro abbiamo davanti a noi stimandolo e quanto pensiamo di poter fare ad esempio in iterazioni di due settimane, tramite la misurazione della velocità.

Mettendo assieme le nostre stime e la velocità, possiamo avere una proiezione di quando riusciremo a completare il nostro lavoro, o viceversa quanto lavoro possiamo completare entro una certa data.

Chiunque abbia familiarità con un progetto agile dovrebbe riconoscere la serie di termini di cui parlerò a breve ma che spiegherò sia come ripasso che per quei CTO e leader tecnologici ancora principianti in questo ambito.

Chiaramente questo non è un elenco esauriente per racchiudere l’intero contesto di un processo di sviluppo del software, ma è comunque sufficiente per quanto riguarda l’argomento delle stime.

Innanzitutto parliamo di Backlog, detto anche Product Backlog, che è quell’elenco di item e desideri messi in priorità che il team di sviluppo deve realizzare e consegnare. Questo può essere implementato come un foglio elettronico, dei post-it in una lavagna o all’interno di strumenti come Trello o Jira.

Poi abbiamo i Backlog Item, che sono i singoli item o card all’interno della lista del Backlog che come minimo dovrebbero avere un titolo, i dettagli, possibilmente i criteri di accettazione, la stime e il tipo di item.

I tipi possono ad esempio essere:

• User Story, che rappresentano le nuove funzionalità o i miglioramenti al prodotto che cambiano in modo tangibile l’esperienza degli utenti;
• Bug, relativi a comportamenti inaspettati da correggere e che vanno gestiti, prioritizzati e stimati a tutti gli effetti come se fossero delle user story;
• Eventuali lavori di routine o Task Tecnici, che sono invece item ai quali non corrispondono differenze visibili nell’esperienza degli utenti e che tipicamente non sono verificabili direttamente da un Product Owner non tecnico, come ad esempio il refactoring per smaltire debito tecnico di cui ho parlato nelle precedenti puntate del podcast, l’integrazione con un servizio di logging, l’implementazione di un sistema di backup, ecc. Un lavoro di routine potrebbe anche comportare il lavoro richiesto per avere informazioni su altri item, come ad esempio la scrittura di un Proof of concept per testare la complessità di una certa funzionalità o integrazione, oppure un’attività di analisi o di software selection.

Infine abbiamo gli Story Point, che consistono in un numero che rappresenta quanto è grande un certo item in rapporto agli altri che sono presenti all’interno del Backlog, perciò vanno intesi come stime relative principalmente in termini di complessità, di quantità di lavoro necessario per realizzare il relativo item, o in termini di altri fattori di rischio e non direttamente di ore o giornate di lavoro.

A questo punto possiamo vedere come si stima in modalità agile, innanzitutto parlando dei range di stima.

Tendenzialmente si usano degli intervalli di Story Point di questo tipo: 1, 2, 3, 5, 8, 13, 20, 40 e 100, ad esempio davanti a me ho un mazzo di carte da Planning Poker della Wibas che ha proprio questi valori oltre a quelli come lo 0, 1/2 e la carta del caffè che si usa quando si è stanchi dopo una lunga sessione di stime.

La prima parte da 1 a 13, quindi i numeri più bassi, vengono generalmente assegnati agli item nel Backlog quando il team ha una visibilità sufficiente su come affrontarli. La loro dimensione tende a essere quindi determinata più dalla complessità e dallo sforzo percepito per completarli.

La seconda parte da 13 a 100 è solitamente associata a delle User Story da suddividere, perché sono in realtà delle Epic. La loro dimensione tende quindi ad essere determinata più dal rischio e dall’incertezza.

Spesso poi si usano anche valori come 0, 1/2, “?” e “Infinito”, ma possibilmente li eviterei perché focalizzarsi sugli zero e gli 1/2 incoraggia il team a dedicare del tempo a discutere sulla dimensione delle funzionalità più piccole che hanno il minor impatto su tempi e costi.

Invece includere “?” e “Infinito” consente al team di non quantificare il rischio percepito di un certo item e in più non consente di definire la somma di Story Point di uno Sprint.

E’ invece meglio per un CTO o un Product Owner usare un sistema dove gli item più rischiosi e incerti nel Backlog incrementano il totale di punti del Backlog stesso, in modo da motivarlo a ridurne il rischio e suddividerlo in parti più piccole.

Fatto questo, bisogna impostare i punti di riferimento.

Quando si affronta un nuovo Backlog di item non stimati con il proprio team, all’inizio la cosa può sembrare scoraggiante.

In quel caso bisogna iniziare esaminando alcuni di quegli item meglio definiti o quelli in cui il team ha almeno qualche idea su come affrontarli.

Quindi, bisogna trovare un item di piccola dimensione, ma non il più piccolo: quello può essere il primo item da 2 Story Point.

Poi bisogna trovare un’altra User Story che è circa tra le 2 e le 4 volte più grande, e quello diventa un item da 5 Story Point.

Per fare questo non è necessario partire con il planning poker, basta scegliere qualcuno che chieda al gruppo di accordarsi o meno sulla User Story da 2 Story Point e poi quella da 5 Story Point.

Ricordandosi, nel fare questo, che i punti sono una stima relativa delle dimensioni e non del tempo necessario per implementare la User Story.

Bisogna quindi evitare di associare automaticamente un certo numero di ore lavorative agli Story Point, perché altrimenti non staremmo facendo altro che stimare direttamente in ore e a quel punto l’intero concetto degli Story Point perde di valore e tanto varrebbe procedere con le stime nel modo classico.

Chiaramente ci possono essere delle attività come quelle di analisi oppure di task ripetitivi che sono già stati svolti nello stesso modo in altre occasioni che in alcuni casi potrebbero quindi essere associati ad un certo numero di ore, in quel caso ci può stare che quelle attività vengano stimate in ore.

Il punto è che gli Story Point si utilizzano principalmente per fare delle stime, o meglio delle previsioni, relativamente al compiere attività che hanno un certo grado di incertezza o di novità.

Proprio per questo grado di incertezza, è anche inutile scendere ad un livello di dettaglio molto elevato in fase di Sprint Planning, perché così le stime occuperebbero molto tempo e potrebbero portare alla paralisi il team.

E’ importante scendere a quel livello di dettaglio in fase di lavoro durante lo sprint, ma in questa fase la stima va considerata più come se fosse un processo di triage per classificare la dimensione delle richieste e delle funzionalità da sviluppare.

Questo è un punto importante da comprendere, perché se si gestiscono gli sprint planning per la parte relativa alle stime proprio come se fossero una sorta di triage allora migliorerà l’intero processo.

Per oggi siamo a posto con questa prima puntata del podcast dedicata alle stime nei progetti gestiti con Scrum, grazie per averla ascoltata, nel prossimo episodio riprenderò l’argomento parlando del Planning Poker e fornirò alcuni suggerimenti basati sulla mia esperienza per affrontare la stima di interi nuovi progetti.

Se hai bisogno di consulenza o supporto per impostare al meglio le stime con il tuo team di sviluppo, o per capire meglio perché i tuoi sviluppatori hanno problemi con le stime, puoi contattarmi tramite Axelerant.

Nel frattempo se vuoi approfondire questo argomento o vuoi riportare la tua esperienza, oppure se vuoi suggerire un argomento per le prossime puntate, puoi iscriverti alla nostra community e scriverci nel gruppo dedicato.

Grazie ancora e al prossimo episodio, ciao da Alex.