Non era nello Sprint Backlog: item non pianificati, e tecniche del prigioniero

-Una misura è una riduzione di incertezza espressa quantitativamente sulla base di una o più osservazioni. - (Douglas W. Hubbard - How to Measure Anything)

- Ogni Buon Regolatore di un sistema deve essere un modello di quel sistema (R.G. Conant, W.R. Ashby)

Vediamo qualche modo per visualizzare informazioni "non standard" sulla taskboard.

Ciò che non è stato deciso in fase di Sprint Planning Meeting, proposto dal P.O. e stimato dal team, non dovrebbe esistere.

Tuttavia a volte garantirlo è difficile, c'è il "firefighting", emergenze non rimandabili che sopraggiungono. Come si può fare a mantenere comunque consistenti le informazioni degli information radiator e le relative misure?

Mettiamo di avere nello sprint backlog quattro items per un totale di 10 story point.

Diciamo che il team è composto da due persone (poche rispetto allo standard, ma è per semplificare) e che lavora su generici "item" dotati di stima in story point.

Giorno 0. Nello sprint backlog ci sono quattro item:

Al primo giorno vengono selezionati e spostati in "doing" gli item A e B:

Passa un giorno. La taskboard si presenta come segue:

Gli item che si trovano in doing sono stati marcati con una barretta per indicare che è passato un giorno, un po' come farebbe un prigioniero in una cella.

Nel giorno successivo le cose restano invariate, e viene aggiunta un'altra barretta ad entrambi gli item, mentre il burn down resta piatto.

All'inizio del quarto giorno risulta che l'item A è terminato, vengono sempre aggiunte le barrette per il tempo passato in "doing", il burndown si abbassa di tre punti...

...e si mette l'item C in doing:

Passa un altro giorno, vengono aggiunte le barrette agli item che sono in "doing":

Il giorno 6 risulta terminato l'item B, e quindi viene preso in carico D:

Durante la giornata C viene interrotto per far posto ad una attività imprevista (Unplan):

Mediante un nuovo grafico "burn up" verrà tracciato il tempo che si spenderà in queste attività "unplanned":

A differenza del burndown, in questo grafico i valori dell'asse Y sono espressi in unità di tipo tempo-uomo, e non in story point.

All'item C, che è rimasto in sospeso perché interrotto, viene aggiunta comunque una nuova barra, questa volta rossa, per mettere in evidenza la quantità di tempo in cui l'item è rimasto bloccato.

Sì continua allo stesso modo al giorno 8:

Nel giorno 9 l'attività D è terminata...

... quindi le attività in corso posso essere parallelizzate:

Al giorno 10 l'attività unplanned è terminata:

Uno dei due membri del team è libero, e potrebbe aiutare l'altro componente del team o approfondire qualche argomento. Per "quadrare" i conti, si introduce un item fittizio "slack".

Il giorno 11 finisce lo sprint, e le attività sono tutte concluse:

In sintesi:

- il totale delle barre nere è il numero di giorni/uomo che abbiamo avuto a disposizione durante lo sprint

- il totale delle barre nere degli item pianificati è il numero di giorni uomo spesi per quanto deciso durante lo Sprint Planning.

- le barre rosse rappresentano il tempo in cui certe attività sono rimaste "bloccate".

- il burn up chart, oppure il totale delle barrette nere degli item non pianificati e degli slack, mostrano il tempo uomo speso in attività non pianificate.

- il burn down funziona al solito modo.

Sulla velocità:

se gli item non pianificati e lo slack fossero rimasti "invisibili", avremmo detto che la velocità del team è stata di 10 story point, ma in realtà dei 20 giorni uomo a disposizione nello sprint, solo 15 sono stati utilizzati per gli item pianificati, altri 4 per un item non pianificato, e uno per lo "slack time".

Possiamo ricavare la "velocità netta".

Perché dovremmo farlo?

La velocità netta permette di conoscere il valore atteso di quella che sarebbe stata la velocità totale se lo Sprint non fosse stato "inquinato", e quindi rende confrontabili le velocità di sprint diversi.

Un modo rapido per calcolarla è moltiplicare il numero di story point portati a termine per il numero di giorni uomo dello sprint diviso il numero di giorni uomo effettivamente utilizzati per i planned items: 10 * 20 / 15 = 13.33

Il numero medio di story point per giornata è 1.33. Siccome il team è di due sole persone, dividiamo per due per ottenere il numero medio di story point per giorno uomo: 0.66.

Oltre ad avere proiezioni sulla velocità "reale", si possono incrociare queste informazioni in altri modi, per esempio per discuterne in una retrospettiva.

Per ogni item sappiamo di quanto si è discostata la velocità rispetto alla media.

Per esempio per l'item A, stimato in 3 story point, la velocità effettiva è stata di 3 giorni uomo. La media degli story point in tre giorni è 0.66 * 3 = 2. Quindi per quella storia un "bilancio positivo" di 1 story point.

Questi valori possono essere aggiunti in rosso nelle user story.

Da notare che si compensano a vicenda e dunque la loro somma deve fare zero.

Si possono poi ordinare su una"timeline", sull'asse X rispetto al tempo, e sull'asse Y rispetto allo scostamento dalla media, per avere una visione di come sono distribuiti nell'arco dello sprint.

(La collocazione degli item di tipo unplan e slack è arbitraria rispetto all'asse Y.)

Con la colorazione rispetto alle aree tecnologiche, possiamo anche vedere la correlazione di tali valori rispetto alle aree tecnologiche stesse.

Per questo tipo di analisi anziché di item di tipo user story, parliamo di task.

I task sono legati alle componenti tecniche. In teoria non sarebbero da stimare in story point, ma possiamo assumere che "ereditano" il numero di story point attribuito dalla user story a cui appartenevano.

Dalla distribuzione dei colori rispetto all'asse Y si può avere una visione di insieme su alcune criticità dello sprint:

Sembra che gli item blu siano andati meglio del previsto, a differenza dei gialli.

Per spiegarcene le ragioni possiamo integrare in queste viste anche valori relativi alle competenze della skill matrix.

Tipicamente una entry nella skill matrix è vuota, oppure ha un punto, o un asterisco.

Quando un componente del team lavora su un task di una certa area tecnologica, ricopiamo sul task stesso il suo grado di competenza relativo, come da skill matrix, cioè un asterisco, un punto o niente.

Nel redistribuire gli item alla fine dello sprint abbiamo qualcosa come:

Si vede che gli item che sono andati meglio della media sono stati portati a termine da persone che secondo la skill matrix erano i più competenti in quell'area. Questo non sorprende.

Le informazioni che emergono possono essere interpretate in diversi modi: per esempio per ri-aggiornare la skill matrix, per verificare se non siano state sottovalutate le complessità di particolari aree tecniche, e così via...