Backlog zero

Gestire il backlog è un compito che diventa sempre più difficile man mano che un progetto va avanti. Le card (o i ticket) che lo compongono diventano sempre di più e diventa sempre più difficile capire quali di questi sono importanti e urgenti, quali sono sogni ad occhi aperti e quali si riferiscono a cose non più attuali.

Alcuni provano a risolvere il problema creando complessi meccanismi composti da etichette di vario tipo, categorizzazioni, divisione per epiche, stime premature e magari workflow di jira personalizzati, fino a far diventare il backlog una cosa così complessa che si ha timore di metterci le mani per paura di sbagliare.

A me attirano più le soluzioni semplici ma estreme, come quella che vi sto per raccontare, non credo abbia un nome, ma mi ricorda molto la modalità “inbox zero” di gestire il disordine della propria mail.

Come funziona

L’idea è quella di gestire il backlog con solo due colonne in una board:

• La colonna “Proposte”: questa si riempirà ogni settimana con le nuove card proposte dagli stakeholder o dai membri del team

• La colonna “Prossime da fare“: che contiene le prossime card da fare. La cosa particolare è che ha un limite, non ci possono stare più di N card, orientativamente direi circa il numero di card che vi bastano per 2-3 settimane di lavoro.

Ogni settimana (o ad ogni iteration meeting) nella riunione di pianificazione si prende ogni card in “Proposte” e discutendone, ci si domanda se vale la pensa inserirla nel progetto:

• Se non è ritenuta utile, ovviamente si cestina.

• Se potrebbe essere utile, ma non è rilevante per gli obiettivi delle prossime 2-3 settimane di sviluppo si cestina.

  La persona che l’ha proposta si preoccuperà di riproporla in un momento più adatto (se nessuno se ne ricorda probabilmente non era così importante).

• Se potrebbe essere utile adesso ed aggiungerla nelle “Prossime da fare” farebbe sforare il limite, si valuta se è più importante di qualcuna di quelle già presenti.

  Nel caso positivo la si sostituisce con quella meno importante delle “Prossime da fare”, nel caso negativo la si cestina. Come al solito si è liberi di riproporla successivamente.

• Se potrebbe essere utile e la colonna “Prossime da fare” ha spazio a sufficienza, la si sposta lì.

Quindi alla fine della riunione avremo la colonna “Proposte” vuota, la colonna “Prossime da fare” con poche card (perchè deve rispettare il limite), ed una direzione precisa in cui andare.

Ma soprattutto avremo guadagnato la consapevolezza di stare lavorando sulle cose più importanti che ci sono venute in mente per il nostro obiettivo e ci saremo anche liberati dall’inquietudine di giganti cumuli di card di cui nessuno può avere il controllo.

Vantaggi

Questo processo porta a vari effetti positivi, tra cui:

• la board è sempre composta da poche cose importanti ed utili nel breve periodo, più qualche proposta che viene valutata prontamente

• viene sollecitata la partecipazione da parte di chiunque, indicando un modo semplice per fare proposte, ma vengono subito scartate le proposte fuori tema. Questo abitua il team a mantenere il focus.

• per poter fare questa selezione così stringente di card, costringe a chiarire bene l’obiettivo delle prossime settimane

Quando è efficace

Dalla mia esperienza le situazione ideale è quando si vuole far evolvere un prodotto già sul mercato, nella fase di sviluppo iniziale potrebbe invece far più comodo qualcosa che ti dia una visione più globale tipo uno User Story Mapping.

Un altro caso in cui questo metodo potrebbe essere controproducente è se la maggior parte delle tue card sono bug, in quel caso cestinarli potrebbe non essere una buona idea (anche se comunque avere un grande archivio di bug irrisolti non è che sia molto più utile).

Chi usa metodi simili

Ho visto usare questo metodo in maniera consistente per la prima volta in Soisy, mentre nel libro Shape up si parla di “No backlogs” per portare avanti le iniziative software, ma è a livello molto più macro.

Photo credits: Emilio Scanavino – Tramatura con cerchio (1973)