Il Product Backlog e i suoi elementi

In un progetto gestito tramite la metodologia Scrum, normalmente il team (PO + Scrum Master + team di sviluppo) concentra il suo lavoro intorno al Product Backlog che, come abbiamo avuto modo di vedere in numerosi articoli, altro non è che una pila di elementi (si parla appunto di Product Backlog Items) ognuno dei quali rappresenta un pezzo di funzionalità del sistema che si deve realizzare.

Una delle caratteristiche fondamentali del Product Backlog (PB) è che deve essere organizzato in modo che sia sempre ordinato in base alla priorità delle funzionalità: in alto si mettono quegli elementi che si vuole siano realizzati per primi. A scendere troveremo gli items che potranno essere realizzati successivamente perché in ottica relativa portano meno valore e quindi potranno essere realizzati dopo. È compito del Product Owner stabilire l’ordine del backlog.

Per questo motivo le cose che stanno in alto nel backlog devono essere compatibili con la lavorazione nell’arco di uno sprint: si parla infatti di elementi “lavorabili” o pronti per la lavorazione.

Raffinamento del Product Backlog

Il Product Owner, insieme al team, durante lo sprint esegue il cosiddetto raffinamento del backlog che si traduce da un lato in un costante riordinamento delle storie, dall’altro nella scomposizione di elementi grandi in elementi più piccoli.

Storie utente di piccola dimensione

Scrum non prevede alcun formato particolare per gli elementi del backlog, lasciando massima libertà al team: nella maggior parte dei casi si utilizza però il formato delle User Stories.

Non ci addentreremo in questa sede nello spiegare perché sia importante arrivare a scomporre le storie grandi in storie più piccole, essendo questo un argomento di cui si è già avuto modo di parlare abbondantemente in passato, né perché sia così importante rispettare il pattern INVEST: per chi fosse interessato ad approfondire tali argomenti, consigliamo la lettura degli articoli pubblicati in passato dedicati a Scrum e che — riveduti, corretti e ampliati — sono poi confluiti nella parte su Scrum della nostra Guida Galattica per Agilisti [1].

Creare gli elementi del backlog

Una delle regole fondamentali da rispettare nella creazione degli elementi del backlog è instaurare un formato che non solo consenta la discussione, ma che anzi la favorisca: lo scopo della discussione è di confermare al PO se ha una buona comprensione delle esigenze degli utenti e, contemporaneamente, se è riuscito a trasferirla al team di sviluppo.

Quando tutto il team è coinvolto nella discussione, lacune funzionali, incoerenze e requisiti poco chiari vengono scoperti più velocemente rispetto a quando una sola persona è coinvolta nello scrivere i dettagli.

Il formato Connextra

Nel capitolo dedicato alle storie utente del libro Guida Galattica per Agilisti [1] abbiamo lungamente parlato del formato da utilizzare per la descrizione degli elementi da inserire nel backlog. Si era detto che, sebbene la metodologia non suggerisca ufficialmente alcun formato specifico, nella maggior parte dei casi le funzionalità sono espresse tramite il formalismo delle User Stories rappresentato dal Connextra card template: “In qualità di…”, “vorrei…” “affinché…”.

Come avremo modo di vedere, si tratta di un ottimo strumento; ma, come tutti gli strumenti… è uno strumento. La prima raccomandazione è quindi quella di utilizzarlo con coscienza, evitando di farne l’implementazione da Cargo Cult: “Ci hanno detto che le storie si scrivono con questo formato, quindi usiamo questo formato, senza porci troppe domande”.

Una delle caratteristiche più interessanti di questo template è che abilita la discussione e il confronto: propone un deliverable (il “vorrei che…”) che viene direttamente collegato con un beneficio immediato (l’“affinché”) cosa che spesso aiuta in modo considerevole la discussione.

Il rischio di storie mal formulate

La disponibilità di un formato come quello presentato non elimina comunque il rischio che la compilazione avvenga in modo piuttosto meccanico e poco sensato. Per esempio, storie compilate nel modo che vediamo subito di seguito sono un chiaro esempio di storie poco utili, o tali da non consentire il lavoro del team di sviluppo:

“In qualità di PO vorrei che il dev team implementasse questa funzionalità affinché…” (spesso questa ultima parte manca)

Oppure:

“In qualità di trader vorrei una funzione trading affinché possa fare operazioni di trading”

È chiaro che, con situazioni di questo tipo, occorre lavorare per realizzare invece storie utente di valore.

Identificare bene gli attori

Una cosa da evitare in modo deciso è trasformare le storie in uno strumento per la raccolta di features del prodotto. Una User Story deve invece vedere le cose nell’ottica delle necessità di business dell’utente finale e non deve rappresentare un elenco delle funzionalità del sistema — che dovrebbero arrivare come soluzione del bisogno espresso dalla storia — o, peggio ancora, essere una soluzione implementativa già prestabiltà, visto che questo è il compito del Development Team.

Il formato delle user stories, concentrando l’attenzione sull’utente e non sulle funzionalità, è molto potente per costruire un prodotto finale che risponda realmente alle necessità dell’utente. Per questo motivo è estremamente importante che i ruoli non siano espressi in modo generico ma in modo preciso e dettagliato: occorre evitare quindi formule tipo “In qualità di utente vorrei…” ma provare a specificare sempre il nome del ruolo.

Sostituire i ruoli generici

A volte accade che si usino termini generici come utente, cliente, utilizzatore proposti inizialmente come “riempitivo” nel modello della scheda, ma che poi finiscono per rimanervi, spingendo infine a costruire funzionalità prive di valore o fuori dallo scope all’interno del backlog.

Descrizione della storia

Nel caso in cui la storia contenga un breve descrizione di quello che dovrà essere realizzato, è sempre bene che sia una descrizione del problema e che contenga un contesto, per far si che il programmatore possa arrivare a formulare una soluzione efficace e non una sua interpretazione.

Per esempio “Identificare l’ammontare del denaro bloccato per lo sviluppo di progetti” potrebbe essere una buona descrizione del problema, mentre “Cash report” non lo è affatto, visto che fornisce già una soluzione (“Fatemi un resoconto”): nel primo caso si potrebbe rispondere alla richiesta implementando una finestra pop-up che contenga il totale del denaro raggruppato e formattato in qualche modo, al posto del classico report tabellare.

Puntare al cambiamento del comportamento

Un modo spesso efficace per concentrarsi sul bisogno dell’utente e non proporre una soluzione è quello di descrivere il cambiamento di comportamento del sistema che si può ottenere grazie all’implementazione della storia.

Nel libro The Learning Alliance [3] si ipotizza che le iniziative di valore producano un cambiamento osservabile nel modo di lavorare di qualcuno. Questo principio può essere applicato con semplicità anche come spunto per attivare una discussione sul valore di una storia, e magari per sbloccare una situazione difficile.

Riprendiamo l’esempio dei report di cui parlavamo sopra. Volendo descrivere la storia in termini di cambiamento, si potrebbero usare le seguenti formule: “Ottenere la visualizzazione del sommario mensile in tempi più rapidi” o “Aggiungere la visualizzazione del rapporto di sintesi”.

In definitiva possiamo dire che una storia non dovrebbe limitarsi a descrivere il comportamento del sistema — o meglio dell’attore che userà una determinata funzione — ma piuttosto provare a descrivere il cambiamento nel comportamento che questa storia introduce.

Storie utente e metriche

Molto spesso, descrivere un cambiamento di comportamento semplifica la valutazione del valore di una storia anche dal punto di vista del business. Un buon metodo pratico per descrivere un cambiamento di comportamento è quello di provare a introdurre qualche metrica oggettiva e misurabile

Qualora non sia possibile esprimere un valore preciso (“si vuole un incremento del 20%”) si potrebbe provare a descrivere il valore minimo o massimo accettabile, con l’accortezza che la risposta deve arrivare entro 1 secondo, senza troppe elucubrazioni. Quando si tratta di nuove funzionalità da introdurre, può essere difficile quantificare il miglioramento: in questo caso può bastare anche anche un semplice “smettere di fare…” o “iniziare a fare…”.

Zona di controllo e sfera di influenza

Leggendo il libro Fifty Quick Ideas to Improve Your User Stories [3] ho trovato molto interessante una serie di considerazioni legate al formato delle storie e alle implicazioni delle cosiddette “zona di controllo” e “sfera di influenza”.

In un sistema, la zona di controllo include tutti quegli elementi sui quali abbiamo potere di intervento e sui quali possiamo agire per apportare un cambiamento.

La sfera di influenza, invece, include quelle attività su cui possiamo influire, ma sulle quali però non abbiamo un controllo diretto.

Il contesto esterno include infine tutti gli elementi sui quali non abbiamo modo di influire in alcun modo.

Rapporto tra storie utente, zona di controllo e sfera di influenza

Queste tre aree (figura 3), e i confini che le separano, forniscono una chiave di lettura molto interessante su ciò che un un team di sviluppo può sperare di ottenere con l’implementazione delle user story.

Per esempio, esiste una regola molto semplice e pragmatica che dice che ciò che identifica il bisogno utente (la parte “affinché…” della storia) dovrebbe collocarsi nella sfera di influenza del team, mentre il deliverable (la parte “vorrei che…” della storia), che è poi ciò che verrà implementato, dovrebbe ricadere nella zona di controllo del team (figura 4).

Non è una regola valida universalmente, e ci sono svariate eccezioni… ma qualora ci si dovesse accorgere che la storia non sta in questo schema, potrebbe intanto essere utile investigare per capire se c’è qualcosa che non va.

Confondere gli ambiti di intervento

Un antipattern tipico è quello in cui il bisogno utente ricade nella zona di controllo del gruppo di sviluppo. In questo caso è probabile che l’implementazione della storia sia semplice, immediata e senza che il dev team debba sperimentare troppo: si dice in gergo che in questo caso la storia non è sfidante.

Questo scenario dovrebbe far sorgere qualche sospetto, se non addirittura una preoccupazione: la storia in esame potrebbe essere inutile, “falsa” — o meglio, legata a falsi bisogni di business —, potrebbe essere troppo piccola o fuorviante.

Storie inutili, false, troppo piccole e fuorvianti

Imparare a riconoscere le storie utente che hanno scarso valore ci può aiutare nella nostra strategia per la realizzazione di user stories che invece siano cariche di valore, il che è il nostro obiettivo primario per realizzare un sistema che soddisfi i bisogni che ne hanno decretato la necessità.

Storie inutili

Una storia potrebbe essere inutile quando non implementa alcun reale bisogno utente, ma solo qualcosa che non risolve una reale necessità. Sembra impossibile come concetto, ma la realtà è ben diversa: il nostro Product Backlog è sempre a rischio di ospitare storie inutili.

Storie false

Una storia è invece falsa quando non è pensata per soddisfare un bisogno di business dell’utente, ma più probabilmente quello del team stesso: in pratica, rispone a un “falso bisogno” almeno dal punto vista delle richieste dell’utente. La necessità di migliorare un qualche componente del sistema, per quanto legittima, spesso non è proprio un bisogno dell’utente ma del team di sviluppo; in questo caso potrebbe essere più onesta una formulazione come questa: “In qualità di sviluppatore, vorrei un sistema di start/stop del servizio XYZ per testare più rapidamente”.

Storie troppo piccole

Le micro-storie invece derivano dal lavoro di scomposizione di una storia più grande il cui risultato è qualcosa di troppo piccolo, che non necessita un lavoro “sfidante” (risky) per la sua lavorazione. Sono di fatto una frazione di qualcosa che potrebbe essere più grande. Le micro-storie non sono necessariamente sempre una cosa negativa, ma è importante tenere traccia della storia più grande da cui sono state estrapolate, per collegare il completamento con successo delle une alle altre.

Non sempre, però, l’implementazione delle varie micro-storie risultanti dalla scomposizione di una storia più grande può risolvere il bisogno di business complessivo della storia di partenza: la teoria della complessità conferma che il meccanismo di scomposizione e ricomposizione senza ulteriori conseguenze vale solo in un dominio semplice o al massimo complicato, ma non in uno complesso [4].

Per non rischiare di rimanere ingabbiati nel meccanismo delle micro-storie, potrebbe valer la pena di riconsiderare l’utilità della scomposizione: magari è possibile lavorare direttamente già sulla storia complessiva, oppure si può effettuare la scomposizione seguendo però una grana differente.

Storie fuorvianti

Le storie fuorvianti (o “ingannevoli”), infine, sono quelle che descrivono una soluzione e non un bisogno utente. Un esempio di questo tipo di storie è riportato nel libro di Adzic ed Evans citato [3] e potrebbe essere qualcosa di questo tipo: “In qualità di utente del sistema di backoffice, vorrei che il sistema di creazione delle query sul database fosse ottimizzato, cosicché possa ottenere i report in tempo più rapido.” Sembra una storia concreta, introduce un cambiamento misurabile nel comportamento dell’operatore. In realtà l’ottimizzazione delle query sul database è un qualcosa alla portata diretta del team di sviluppo che si potrebbe mettere immediatamente all’opera per ottenere tale risultato.

Nell’esempio raccontato nel libro, questa cosa genera qualche sospetto che spinge a indagare ulteriormente. Dopo alcune verifiche si scopre che la velocizzazione del sistema era un requisito richiesto dall’utente finale, il quale aveva la necessità di identificare alcune discrepanze fra i risultati ottenuti come risultato di differenti ricerche.

In quel caso, la ricerca flat su tutto l’archivio richiedeva troppo tempo, tanto da ostacolare il lavoro di comparazione. Queste indagini portarono alla scoperta che il vero obiettivo non era tanto ottimizzare le ricerche, ma permettere la comparazione sulle discrepanze, cosa che poteva essere realizzata semplicemente implementando una funzione di tipo differente.

Storie fuori controllo

Quando la storia è fuori dalla zona di controllo del team, questo significa che ci sono due possibili situazioni: le aspettative sono completamente irrealistiche oppure la storia non è effettivamente realizzabile dal team nel quale, a quel punto, è necessario introdurre nuove risorse, conoscenze, persone, etc.

Il primo caso è piuttosto semplice da gestire, basta scartare la storia. Il secondo invece è più interessante: potrebbe essere necessario il coinvolgimento di uno specialista esterno al team, o di un’altra parte dell’organizzazione (la divisione finanziaria o altro).

Questo tipo di ingaggio, richiede un po’ di tempo e di energie per il coordinamento: spesso le organizzazioni, in previsione di scenari di questo tipo, organizzano i gruppi di lavoro separando il core team — le persone che lavorano a tempo pieno nel team di sviluppo — da una serie di Subject Matter Expert (SME), inseriti spesso come se fossero consulenti esterni, quindi seguendo una ben precisa procedura di ingaggio snella e semplice.

Il processo di valutazione delle storie al fine di identificare quali sono all’interno della la zona di controllo o della sfera di influenza, permette di comprendere in modo piuttosto rapido quali storie potrebbero subire dei ritardi in attesa degli specialisti: per queste storie potrebbe convenire attivarsi per tempo in modo da capire prima possibile quali saranno gli SME necessari per il completamento.

Comprendere il valore di una storia utente

I concetti di zona di controllo e sfera di influenza sono molto importanti dal punto di vista sistemico (o del systems thinking volendo usare una definizione molto in voga ultimamente): capire se una storia, ossia un bisogno utente, sta dentro o fuori permette di intervenire sulle cause del problema ed eventualmente risolverlo invece di curarne semplicemente i sintomi, nel caso in cui il team o l’organizzazione effettivamente non sia in grado di risolvere un bisogno dell’utente.

È importante considerare che il confine del sistema può variare notevolmente in funzione del punto di vista che si usa per l’osservazione. Per questo può convenire prendere in esame il punto di vista del team di sviluppo, che è di fatto chi deve poi implementare la storia.

Se la storia non rispetta il pattern di cui sopra, una soluzione può essere quella di provare a scomporla o riscriverla, magari eliminando storie false o fuorvianti. Le micro-storie potrebbero in questo caso introdurre un livello di dettaglio troppo fine per il tipo di pianificazione presa in considerazione (medio-lungo termine).

Se si dovessero identificare storie che solo in parte possono ricadere nell’ambito della sfera di influenza / zona di controllo, si potrebbe pensare di spezzarle e di procedere alla realizzazione della parte fattibile: è una riorganizzazione del lavoro che può contemplare la rimozione della parte non realizzabile.

Conclusioni

Con questo primo articolo abbiamo voluto fornire una serie di consigli pratici volti ad affrontare il tema del raffinamento del backlog e della creazione di storie utente che siano effettivamente di valore.

Attraverso l’analisi dei tipi di user stories di scaso valore, e con l’introduzione del pattern di valutazione basato sulla zona di controllo e sulla sfera di influenza, abbiamo presentato alcuni “strumenti” operativi che possono aiutarci nella non facile arte di realizzare storie effettivamente allineate ai bisogni di business dell’utente.