Nessuna stima dello Sprint Backlog con i Task Point

Quando nel 2005 scrissi il libro Agile Estimating and Planning, mi occupavo già da cinque anni di diversi metodi di stima. Dopo aver condotto esperimenti con alcuni team – in particolare con quelli che lavoravano direttamente per me – avevo la sensazione di aver imparato abbastanza per poter scrivere il libro.

Tuttavia c’erano ancora molte cose che non sapevo (e naturalmente anche adesso!). Per questo cercavo team che stimassero e pianificassero i loro progetti in modo diverso da come facevo io. Alcuni di questi team utilizzavano, oltre agli Story Point, anche dei Task Point per la stima dei loro Product Backlog Item.

Lo trovai interessante. All’epoca ero già un sostenitore degli Story Point – e nel frattempo, grazie ai vantaggi degli Story Point, ne sono diventato un fan ancora più convinto. Tuttavia non riuscivo a capire perché un team dovesse utilizzare i Task Point. Essendo però un grande sostenitore degli Story Point, volevo semplicemente saperne di più sui team che lavoravano con i Task Point.

Riuscii a convincere alcuni team a lasciarmi osservare il loro lavoro, per poterne scoprire di più.

Ciò che scoprii confermò la mia ipotesi che i team non dovrebbero valutare i loro Sprint Backlog Item con i Task Point.

Il principale vantaggio degli Story Point

Il principale vantaggio degli Story Point è che persone con competenze, livelli di esperienza e background diversi possono fornire insieme una stima del loro lavoro.

Prendiamo un esempio non troppo serio e immaginiamo di voler stimare, insieme a un polpo, quanto impegno richiederebbe lavare la mia auto.

Un polpo ha quattro volte più braccia di me. Quindi dovrebbe riuscire a lavare la mia auto quattro volte più velocemente. (Avevo detto che non era un esempio da prendere troppo sul serio. Ma aspetta.)

Il polpo laverà però anche qualsiasi altra auto quattro volte più velocemente di me. Il polpo e io possiamo quindi concordare che la mia piccola due posti vale circa cinque Story Point e un’auto un po’ più grande ne vale dieci.

Gli Story Point permettono al polpo e a me di concordare su un certo numero di punti – anche se il polpo è sicuramente molto più veloce di me.

Task Point

Nei team che osservai, notai che un Task Point era quasi la stessa cosa di uno Story Point. Tutti i team con cui parlai volevano però un’unità più piccola degli Story Point.

Ad esempio, un team che completava dieci Story Point per Sprint poteva realizzare circa 80 Task Point per Sprint.

I team volevano semplicemente un’unità più piccola e precisa per poter monitorare meglio i propri progressi. È come se il tachimetro dell’auto indicasse la velocità in anni luce all’ora. In questo modo sarebbe molto difficile capire se si rispetta il limite di velocità o meno.

Utilizzare unità più fini era una buona idea per molti team. Dopotutto è piuttosto difficile misurare il progresso giornaliero di un team con gli Story Point, quando ad esempio ne completa sette in due settimane. In questo caso gli Story Point sono semplicemente un’unità troppo grande per essere utile.

E le ore?

Esiste però già un’unità più fine con cui ogni membro del team ha già familiarità: le ore.

Osservando i team che stimavano con i Task Point, notai che non c’era alcun vantaggio rispetto alla stima degli Sprint Backlog Item in ore.

C’è una differenza fondamentale tra Product Backlog Item (di solito sotto forma di User Story) e Sprint Backlog Task: su un Product Backlog Item lavorano in genere da tre a cinque persone; forse uno o due programmatori, un tester e magari un designer, un architetto, un analista o un redattore tecnico ecc. Su un Task lavora normalmente una sola persona.

Ciò significa che non tutti i membri di un team devono fornire insieme una stima per un Task, come avviene per un Product Backlog Item. Ognuno nel team ha la possibilità di dare una stima per il Task, ma solo chi alla fine ci lavorerà può fornire la stima definitiva.

Se molto probabilmente solo una determinata persona lavorerà su un Task, allora si dovrebbe prendere la stima di quella persona. Se due o tre persone lavoreranno su un Task, si può far stimare tutti e tre insieme oppure prendere la stima della persona che con maggiore probabilità svolgerà il lavoro.

Se durante lo Sprint il lavoro viene passato a un’altra persona, nel peggiore dei casi le stime cambieranno semplicemente. Se un membro del team più veloce prende in carico il lavoro di un collega più lento, modifica la stima da otto a quattro punti – o viceversa.

Perché non usare i Task Point?

I Task Point non hanno quindi alcun vantaggio rispetto alle ore. Hanno però degli svantaggi rispetto agli Story Point:
- Molti membri del team non li conoscono.
- Servono dei valori di riferimento per poter fare delle stime.
- C’è il rischio che le stime nel tempo non si orientino più ai valori di riferimento originali.

Il mio consiglio sui Task Point

Conclusi la mia esplorazione nel mondo dei Task Point senza essere stato convinto del loro valore. Continuo a essere un sostenitore dello Sprint Planning orientato al commitment, così come lo conosciamo. Forse “Sprint Planning orientato alla capacità” è un termine più appropriato. A mio avviso ha vantaggi significativi rispetto allo Sprint Planning orientato alla Velocity.

Per la maggior parte dei team, lo Sprint Planning orientato al commitment o alla capacità funziona meglio con le ore. Alcuni team seguono questo processo ma tralasciano le stime e le utilizzano solo nelle riunioni per capire cosa possono includere nello Sprint.

Altri team semplicemente non stimano affatto gli Sprint Backlog Item. Ciascuno di questi approcci può funzionare bene una volta che un team ha acquisito esperienza.

Sono contento di aver condotto questo progetto per saperne di più sui Task Point e sui team che li utilizzano.

Quando esamino metodi alternativi per la stima, rimango sempre un po’ deluso quando un nuovo approccio non è migliore di uno esistente. Ma purtroppo succede abbastanza spesso.

Eppure troveremo i miglioramenti continui a cui ogni agilista aspira, se consideriamo il maggior numero possibile di opzioni diverse.

Questo testo proviene dal blog di Mike Cohn ed è stato da noi tradotto in italiano.

Product Owner: compiti e sfide

=> Scopri cosa fa un Product Owner durante la giornata.

Cos’è una Scrum Story?

=> Qui scopri le differenze tra User Story, Epic e Theme.