Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.
Idea principale
In Jira o in qualunque strumento equivalente, la separazione sembra una comodità di classificazione. In realtà produce due code guidate da forze diverse: le funzionalità dalla roadmap, i difetti dall'urgenza, dal supporto, dalla pressione del cliente o da un comitato di prioritizzazione.
Fra le due, nessuno guarda l'insieme dal punto di vista del dolore e del valore. Entrambe le code sono ordinate, nessuna viene confrontata con l'altra.
L'alternativa sta in un solo tipo di card: una card di lavoro, che rappresenta un problema da trattare. Quel problema può venire da un difetto software, da una capacità assente, da una progettazione sbagliata, da debito tecnico — la scelta resta la stessa: quale dolore, quale valore, quale impatto, quale decisione.
Perché è importante
Il daily del mattino serve allora a decidere cosa conta adesso, invece di discutere per venti minuti se l'elemento sia un difetto, una funzionalità, un miglioramento o un rework.
Più in generale: è la struttura dello strumento a decidere cosa è confrontabile. Due code, due logiche, nessuna scelta comune — e questo non compare da nessuna parte come una decisione, perché nessuno l'ha presa.
La separazione per natura del lavoro, del resto, non si ferma ai difetti: backlog di prodotto, backlog tecnico, backlog dei bug, backlog del supporto, backlog di discovery producono lo stesso effetto, moltiplicato. Eppure non si prioritizzano categorie, si prioritizzano dolori, rischi e valore — e l'argomento nato dal supporto che mobilita supporto, data e sviluppo non rientra in nessuna delle caselle. Il ragionamento giusto non è «in quale backlog va questo argomento?» ma «quale problema stiamo affrontando, e di quali persone abbiamo bisogno?».
Strato aggiunto da «Il backlog non è una discarica: è uno strumento d'azione» (2026-06-03).
Sfumature e limiti
L'unità pertinente è lo spazio di prioritizzazione, non l'organizzazione: più team che lavorano su perimetri distinti possono avere più code o più viste senza rompere nulla. Quello che non regge è la frammentazione all'interno di uno stesso spazio di decisione.
Alcune organizzazioni hanno bisogno di un reporting sulla qualità, a volte contrattuale. Tag e metriche bastano, a condizione che non strutturino la coda stessa.
Domande aperte
- Oltre quale lunghezza una coda unica smette di essere leggibile, e come la si suddivide allora senza ricreare due logiche?