Backlog Zero: il problema non è quanti problemi hai, ma sapere quali sono veri.
Il mio backlog diceva 21 problemi aperti. Quelli eseguibili erano pochi: il problema non è quanti ne hai, ma sapere quali sono veri.
In breve. Il mio backlog diceva 21 problemi aperti. Quelli eseguibili davvero erano una manciata: il resto aspettava dipendenze, verifiche, evidence che non avevo. Da lì ho smesso di chiedermi "quanti problemi ho" e ho iniziato a chiedermi "quali sono veri". Lo racconto con quattro casi vissuti nella mia Content Factory, con i numeri osservati e rieseguibili. Quattro casi non fanno una statistica: fanno una prova di esistenza. Pubblicato il 3 ottobre 2026.
Ventuno problemi, quasi nessuno eseguibile
L'altro giorno ho contato le righe del mio backlog: 21 aperte. Poi ho provato a rispondere alla domanda vera, che non è quante righe ci sono ma quante posso eseguire adesso. La voce sull'architettura dei pillar aspettava due audit ancora aperti. Le voci tecniche aspettavano gli stessi audit. Gli articoli senza evidence pronta non erano partiti, giustamente. Alla fine le eseguibili erano poche.
Pensavo che il problema fosse la dimensione del backlog. Mi sono accorto che il problema era la domanda: "21" è un numero che descrive la lista, non il lavoro. E una lista non è lavoro finché non sai, per ogni riga, se è bloccata, da cosa, e cosa manca per sbloccarla.
| Cosa diceva il numero | Cosa diceva la verità |
|---|---|
| 21 problemi aperti | Poche voci eseguibili subito |
| Priorità P1 su 9 voci | P1 bloccate da dipendenze aperte |
| Articoli pianificati | Alcuni senza evidence pronta |
| Segnali di gap | Alcuni mai esistiti (fantasma) |
Il giorno in cui il numero è rimasto fermo e la realtà si è mossa
Abbiamo pubblicato cinque articoli in un giorno. La sonda della verità è passata da 15 a 10 segnali: il mondo era cambiato. Il backlog diceva sempre 21. Stesso numero prima e dopo, realtà diversa. Se avessi guardato solo il conteggio, avrei detto che non era successo niente.
La cosa che non avevo capito è che stavo misurando il contenitore invece del contenuto. Il backlog è un posto dove il lavoro aspetta; "quanto aspetta" non dice niente su "cosa può partire". Dal giorno in cui ho smesso di guardare il totale e ho iniziato a guardare gli eseguibili, le mie mattine sono cambiate: non apro più una lista, apro una scelta.
I segnali fantasma
Il caso più istruttivo è stato quello dei segnali che non esistevano. La sonda che osserva il sito aveva una lista di articoli attesi scritta a mano, con slug immaginati mesi prima. Emettevano gap ordinati per file che non sarebbero mai esistiti con quei nomi: lavoro numericamente presente, ontologicamente assente. Li abbiamo trovati solo perché un giorno i numeri non tornavano con la realtà che vedevamo.
Li abbiamo sostituiti con una lista posseduta dal pack, quella vera, e i segnali sono scesi a quelli reali. Morale scomoda: una parte del mio backlog non era lavoro da fare, era rumore generato dal mio stesso strumento di misura. E il rumore generato in casa è il più difficile da riconoscere, perché ha la firma del sistema.
Perché il backlog viene per ultimo, per disegno
Nel selettore che uso, il backlog è l'ultimo strato di quattro: prima le misure verificate che sbloccano lavoro, poi i segnali osservati oggi, poi le attese di evidence scadute, e solo alla fine la campagna backlog. Non è modestia, è gerarchia epistemica: una riga scritta settimane fa vale meno di una misura di stamattina.
Nel mio pack queste righe vivono in un file che si chiama backlog.jsonl, con dipendenze dichiarate voce per voce, e il selettore del kernel le ordina solo dopo aver guardato misure, segnali ed evidence. Vale lo stesso per gli stati: aperta, in attesa, curata, archiviata non sono sfumature, sono verità diverse. Un backlog che mescola tutto in un numero solo sta facendo esattamente l'errore che dovrebbe prevenire: trattare frasi diverse come se fossero la stessa cosa.
Cosa faccio adesso davanti a un backlog
Non conto più. Chiedo quattro cose, in ordine. Cosa è eseguibile adesso, senza aspettare niente. Cosa è bloccato e da cosa esattamente, con nome e cognome del blocco. Cosa manca di evidence e se quell'evidence esiste davvero da qualche parte. E infine quali voci sono fantasmi: segnali di strumenti, duplicati, attese scadute che nessuno ha chiuso. Quello che resta è il Backlog Zero: non zero problemi, zero problemi di cui non so la verità.
Sui sistemi che si riparano da soli e sui controlli che li rendono verificabili ho scritto qui e qui: questo pezzo è il terzo lato, quello che decide da dove si comincia. E no, non prometto che funzioni su backlog di migliaia di voci gestiti da decine di persone: la mia evidence arriva a decine di voci e un solo proprietario. Ma la domanda "quali sono veri" scala meglio di qualsiasi numero totale, perché non dipende dalla dimensione: dipende dall'onestà delle righe.