Don’t dirty my Backlog!

Che il Product Backlog sia uno degli elementi cardini per il lavoro dei team Agile è una verità sperimentata da tutti i team che hanno intrapreso un percorso di “Agilità” scegliendo di partire da un riferimento simil-Scrum. Accettando la verità assodata che i “requisiti sono imperfetti by design”, il Product Backlog risponde alla necessità di avere uno strumento più flessibile del tradizionale SRS (System Requirements Specification, o comunque lo chiamate) per gestirli.

Se a prima vista la gestione di un elenco di attività (Storie se preferite J) non sembra un lavoro particolarmente complicato ed oneroso, entrando nel vivo della questione viene fuori, invece, che un Backlog “pulito e parlante” è tutt’altro che facile da creare, manutenere ed evolvere.

Non di rado ci si imbatte in Backlog costituiti esclusivamente da dei “placeholder”, come ad esempio: “fare la login”, senza alcuna altra informazione di dettaglio, a partire dai tanto bistrattati Criteri di Accettazione. Proprio questa situazione da il là ad uno degli aspetti primari che possono vanificare il senso stesso del Backlog: avere al suo interno decine e decine di elementi, inseriti preventivamente stile “waterfall”, che rendono praticamente incomprensibile il Valore che dovrebbe essere espresso dal loro insieme.

salad

In pratica, si prende la cattiva abitudine di buttare ogni richiesta, ogni specifica se si vuole, che arriva, direttamente nel Backlog, assegnandogli ogni volta la priorità più alta senza minimamente preoccuparsi di effettuare un opportuno refinementdell’elemento ne tantomeno degli impatti che avrà sul Valore per il cliente e sulle attività in essere.

Un possibile approccio per limitare tale mescolamentoè quello di creare un Basket in cui raccogliere le richieste provenienti dai diversi stakeholder, e, solo successivamente, procedere alla creazione di un elemento da inserire nel Product Backlog che rappresenti l’item lavorato o, eventualmente, la sintesi delle diverse richieste che incidono su un elemento o un’area specifica.

basket

L’idea è quella di creare un’area flessibile in cui raccogliere tutte le informazioni necessarie a soddisfare una Definition of Readyminimale che evidenzia il livello minimo di dettaglio previsto per poter promuovere effettivamente un’attività da Basket Item Product Backlog Item.

Per quanto possa sembrare inizialmente un’attività che va ad “affaticare” le incombenze tipiche del Product Owner, inserendo di fatto un pre-step nella creazione del Product Backlog, una volta assorbita e adattata al contesto, diventa decisamente funzionale e centrale per avere un cosiddetto Healthy Product Backlog.

Si evita, infatti, di trasformare il Backlog in un “repository” di richieste, allungandolo oltre ogni ragionevole dimensione, solo perché non si sa dove mettere le cose. Inoltre, introducendo il concetto di Aging, ovvero di invecchiamento di una attività, si può evitare di avere Zombie Itemche restano nel Backlog anche per molte iterazioni senza alla fine riuscire mai a trovare spazio di realizzazione concreta.

Torneremo presto a parlare del Basket con alcune idee per gestire la prioritizzazione degli elementi e la personalizzazione di tool per poterne creare una versione digitale.

Stay tuned J

Comments are closed.