“Lo mettiamo in backlog”, il modo più comune per dire “no”

Il problema: il documento più onesto dell’azienda

Prova ad aprire il backlog di un software B2B con qualche anno di vita. Quasi sicuramente troverai centinaia di voci: la più vecchia risale a due o tre anni prima, una buona metà è contrassegnata come priorità alta e molti titoli contengono il nome di un cliente, come “Export personalizzato per il cliente X”.

Di alcune voci nessuno ricorda più l’origine, ma nessuno ha il coraggio di eliminarle.

Il backlog tiene traccia di tutto ciò che l’azienda ha accettato di prendere in considerazione, settimana dopo settimana, sotto la pressione di clienti, commerciali e urgenze. Per questo è il documento più onesto che esista in un’azienda software.

Se è enorme, vecchio, tutto urgente e pieno di richieste senza una motivazione, la strategia non c’è.

Le conseguenze si vedono prima nelle riunioni e poi nel prodotto: il team passa ore a riordinare voci che non verranno mai realizzate, ogni sessione di pianificazione riapre le stesse discussioni, e il software cresce per accumulo di richieste accolte, una alla volta, invece che per scelte coerenti.

In questo articolo vediamo perché il backlog si degrada in questo modo, come farlo tornare uno strumento di scelta e come capire, in un’ora di analisi, in che stato è il vostro.

Perché succede: 3 problemi che uccidono il backlog

Nessuno decide di costruire un backlog di seicento elementi.

Ci si arriva una richiesta alla volta, per effetto di tre meccanismi che si rafforzano a vicenda.

1. Aggiungere è istintivo, togliere è una perdita

Il primo meccanismo è cognitivo.

Nel 2021 Gabrielle Adams & co hanno pubblicato su Nature una serie di otto esperimenti, condotti su oltre 1000 partecipanti, che mostrano come le persone, di fronte a qualcosa da migliorare, cerchino quasi sempre soluzioni che aggiungono e trascurino quelle che tolgono.

È esattamente la condizione in cui si lavora su un backlog.

Durante una pianificazione, di fronte a un problema del prodotto, la reazione naturale è aprire una nuova features, e non sistemare quelle che non servono più.

2. Il backlog diventa il posto dove si parcheggiano i no

Il secondo meccanismo è relazionale. Des Traynor, co-fondatore di Intercom, ha scritto che la strategia di prodotto consiste nel saper dire di “no”, e che un prodotto che accoglie ogni richiesta finisce per diventare un archivio di funzioni invece che un prodotto.

Il backlog offre una scappatoia comoda. “Lo mettiamo in backlog” suona come un sì rimandato, evita il conflitto e chiude la conversazione.

Nei progetti che seguiamo è una delle frasi più frequenti, e quasi sempre fa riferimento ad un “no” che nessuno ha avuto il coraggio di pronunciare.

3. Nel B2B si accetta più di quanto si possa realizzare

Il terzo meccanismo riguarda il mercato.

I ricercatori dell’Università di Lund, hanno rilevato nei software orientati al mercato B2B un fenomeno che chiamano “overscoping”: l’abitudine di includere in un rilascio più funzionalità di quante il team possa realizzare.

Tra le cause principali hanno individuato un flusso di richieste ampio e difficile da controllare, proveniente da molte fonti diverse e mai confrontato con la capacità reale del team, insieme alle difficoltà di comunicazione tra chi parla con i clienti e chi sviluppa.

Nel software B2B questo flusso è strutturale, perché ogni cliente ha le proprie esigenze e ogni contratto porta con sé qualche richiesta specifica.

La soluzione: separare ciò che si raccoglie da ciò che si decide

Se il problema è che il backlog fa due lavori incompatibili, la soluzione è dividerli.

Da una parte un archivio delle idee, dove ogni richiesta può entrare senza diventare un impegno; dall’altra un backlog corto, che contiene solo ciò che il team ha deciso di costruire e il motivo per cui lo fa. De seguito vediamo come fare.

Passaggio 1: dare alle richieste un posto che non sia il backlog

Il primo passaggio neutralizza la paura di perdere qualcosa. Nel libro Shape Up viene descritto il metodo di lavoro di Basecamp: quest’ultimo sostiene che i backlog centralizzati fanno perdere tempo e danno al team la sensazione costante di essere in ritardo.

La sua proposta non è eliminare le liste, ma separarle: il supporto clienti può tenere un elenco delle richieste ricevute, gli sviluppatori un elenco dei difetti da sistemare, ma nessuna di queste liste alimenta automaticamente le decisioni su cosa costruire.

Passaggio 2: chiedere ad ogni voce del backlog un perché

Il secondo passaggio pone fine al “parcheggio dei no”. Se il backlog contiene solo ciò che è stato deciso, ogni voce deve poter rispondere a una domanda semplice: quale risultato vogliamo ottenere?

Teresa Torres, con l’opportunity solution tree descritto in Continuous Discovery Habits, offre lo schema più chiaro per farlo.

In cima c’è un risultato misurabile, sotto le opportunità emerse dalla ricerca con gli utenti, sotto ancora le possibili soluzioni e gli esperimenti per verificarle.

Passaggio 3: far scadere ciò che non si muove

Il terzo passaggio riporta il backlog alla capacità reale del team, ovvero il problema individuato dalla ricerca sull’overscoping.

Un backlog utile non dovrebbe contenere più lavoro di quanto il team possa realizzare nei prossimi cicli.

Alcuni strumenti di gestione del lavoro, come Linear, prevedono la chiusura automatica delle voci rimaste ferme per un certo periodo.

Una voce deve guadagnarsi il diritto di restare nel backlog.

La soluzione al lavoro: lo stesso backlog, prima e dopo

Torniamo al backlog da cui siamo partiti, con le sue centinaia di voci, metà delle quali ad alta priorità.

La grande maggioranza delle voci, quelle vecchie, quelle senza motivazione e quelle nate dalla richiesta di un singolo cliente, passa nell’archivio, dove viene etichettata per cliente e per tema.

Nel backlog restano poche decine di voci, ciascuna collegata ad un risultato che il team sta cercando di ottenere.

La richiesta “Export personalizzato per il cliente X” viene registrata come idea, e se nei mesi successivi altri tre clienti chiedono qualcosa di simile, quel gruppo di richieste diventa un’opportunità da valutare, con un peso molto diverso da quello di una singola voce dimenticata.

Le riunioni cambiano di conseguenza.

Invece di riordinare centinaia di voci, il team discute le poche che contano e controlla periodicamente l’archivio delle idee per capire quali temi stanno crescendo.

E il backlog torna a fare l’unico lavoro che dovrebbe fare: dire con chiarezza cosa l’azienda ha scelto di costruire e perché.

I limiti: dove la separazione non basta

Questo approccio ha due limiti, ed è utile conoscerli prima di adottarlo.

Il primo riguarda il contesto. Shape Up nasce in Basecamp, un’azienda con un prodotto unico, team piccoli e clienti che in gran parte acquistano il software senza negoziare personalizzazioni.

Nel B2B enterprise alcune richieste non sono semplici idee: sono impegni presi in un contratto, con una data e una conseguenza economica se non vengono rispettati.

Farle scadere o rimetterle in discussione ad ogni ciclo non è un’opzione.

Vanno gestite a parte, in un elenco di impegni contrattuali con un responsabile e una scadenza, distinto sia dall’archivio delle idee sia dal backlog delle scelte di prodotto, e possibilmente ridotte al minimo già in fase di trattativa.

Il secondo riguarda l’archivio delle idee. La separazione funziona solo se qualcuno lo legge davvero.

Se nessuno lo analizza periodicamente per riconoscere i temi ricorrenti, diventa semplicemente un secondo cimitero di richieste.

Per questo entrambe le liste devono avere un responsabile chiaro e un momento fisso di revisione: senza questo, la separazione sposta il problema invece di risolverlo.

Da dove partire

Prima di riorganizzare qualunque cosa, conviene capire in che stato si trova il backlog.

Non esistono soglie riconosciute che separino un backlog sano da uno malato, ma 4 indicatori, facili da estrarre da qualunque strumento di gestione del lavoro, bastano a capire quale dei tre meccanismi pesa di più.

1. L’età delle voci. Quante voci sono aperte da più di sei mesi, e quante da più di un anno?
2. Il rapporto tra voci aggiunte e voci chiuse. Nell’ultimo trimestre sono entrate più voci di quante ne siano state completate o eliminate? Se succede in modo costante, il backlog cresce più in fretta della capacità del team, come nell’overscoping.
3. La quota di voci ad alta priorità. Se una parte consistente del backlog è contrassegnata come urgente, la priorità ha smesso di esistere, e le decisioni vengono prese altrove.
4. Le voci senza un perché. Quante voci non indicano né il risultato da ottenere né l’utente a cui servono?

---

eyestudios è uno studio di Experience Design che lavora dove la complessità è reale: prodotti digitali articolati, organizzazioni con molti stakeholder, ecosistemi in trasformazione. Non ci fermiamo alla superficie: portiamo strategia, ricerca e metodo nei progetti che richiedono più di un buon wireframe.

Abbiamo lavorato con Unox, Aiko, Shampora, Deliveristo, Restworld, Ulixe Group, Confindustria, Flying Tiger, The North Face, Reply, Gruppo Hera, Alkemy, Mondo Convenienza, Verisure, Unipol, Almaviva, We Are Marketers, PhotoSì, ESA, Reale Mutua.