La legge di J. Little (Little’s Law) è un caposaldo nella gestione delle code e dei processi, ed è espressa come segue:

         Wq = Lq / λ

dove:

• Wq = tempo medio di attesa nella coda di un processo (lead time);
• Lq = numero medio di processi in coda (wip);
• λ = tempo medio necessario al completamento del processo (throughput).

Il senso di questa legge è la formalizzazione di come se si vuole ridurre quanto più possibile il tempo di attesa nella coda, sia necessario intervenire su due fronti: ridurre il numero medio dei processi in coda (Lq) e/o aumentare il tempo medio di esecuzione di un processo (λ). Ma cosa centra tutto questo con la gestione di un progetto software? Ebbene, il nostro Backlog (di Team o di Program che sia), può essere assimilato facilmente ad una coda priorizzata, così come il numero dei processi diventa il numero dei WorkItem in essa presenti e il tempo medio di completamento diventa il numero di WorkItem che vengono completati in una singola iterazione.

Facciamo un esempio:

• User Story presenti nel Backlog = 100;
• N. User Story completati in una iterazione (2 settimane) = 15;
• Wq = numero di iterazioni medie di attesa per una nuova funzionalità.

applicando la formula ottengo che Wq = 100/15 = 6,66 + il tempo dell’iterazione stessa per lo sviluppo. Ciò significa che, in media, per ottenere una nuova funzionalità devo aspettare quasi 8 iterazioni, circa 3 mesi!
Visto così, il nostro approccio sembra tutt’altro che “Agile”, ed è proprio questo il motivo per cui, nei post precedenti, abbiamo più volte ribadito che non è utile avere un Backlog troppo ampio e troppo elaborato, perché questo trasforma il nostro approccio Agile/Lean based in uno condizionato direttamente da una filosofia BigUpFront analysis, anche se applicata in modo inconsapevole.
Per ridurre al minimo il valore di Wq possiamo adottare delle tattiche che mirino a:

• Ridurre Lq
  • Avere un numero sufficiente di User Story (o Feature) a comprendere la vision di ciò che si sta facendo, senza però generare un overhead confusionale;
• Incrementare λ
  • INVEST in User Story;
  • Aumentare la capacità del Team, spingendolo a diventare un High Performance Team;

Riuscendo a diminuire Wq, indipendentemente dalle tattiche adottate, si ottengono degli indubbi benefici nella gestione del progetto:

• Diminuire il Rischio associato alla User Story: più una User Story viene mantenuta in coda, più è alto il rischio che venga superata dall’evoluzione stessa del progetto;
• Diminuzione dell’Effort di popolamento del Backlog: l’inserimento di una User Story richiede lavoro e tale lavoro può risultare inutile se essa diventa superata per l’eccessiva lunghezza della coda;
• Riduzione della Qualità: un Backlog eccessivamente lungo ritarda la possibilità di avere feedback tempestivi, ritardando, quindi, la verifica dell’attinenza di quanto realizzato con quanto realmente atteso dagli stakeholder;
• Riduzione della Concentrazione: se i feedback arrivano troppo tardi, è fisiologico che il Team percepisca le attività annesse alla User Story come “non-urgenti”, rilassando la propria attenzione.