Apri un product backlog reale dopo due anni di vita e di solito trovi la stessa scena: 340 voci, le ultime 200 scritte da qualcuno che ha lasciato l’azienda, una decina di “URGENTE!!!” del 2023 e tre richieste identiche con titoli diversi. Nessuno le tocca più, ma neanche le cancella, perché “non si sa mai”.

Quel documento non è un backlog. È un cimitero di buone intenzioni. Un product backlog sano è l’opposto: una lista corta abbastanza da poterla leggere tutta, ordinata in modo che la prima voce sia davvero la prossima cosa giusta da fare.

Cos’è un product backlog (e cosa non è)

Il product backlog è una lista ordinata e viva di tutto ciò che potrebbe servire al prodotto: nuove funzioni, bug da sistemare, miglioramenti all’esistente, debito tecnico da ripagare, esperimenti da provare. È l’unica fonte di verità su cosa il team potrebbe lavorare in futuro.

La parola chiave è ordinata. Una to-do list mette le cose in fila senza un criterio; un backlog le mette in fila per importanza. In cima c’è quello che ha più senso fare adesso, sotto quello che può aspettare, in fondo le idee che forse non vedranno mai la luce.

Non è un archivio di ogni idea passata per la testa a qualcuno in riunione. Non è un contratto firmato col sangue. E soprattutto non è infinito: un backlog che cresce e basta, senza che nulla ne esca mai (né realizzato né scartato), è un sintomo, non un risultato.

Chi possiede il backlog

La proprietà è di una persona sola: il Product Owner nei contesti Scrum, il Product Manager dove i ruoli sono più sfumati. Possedere il backlog significa una cosa precisa: decidere l’ordine. Chiunque può proporre una voce, ma chi decide cosa sta sopra e cosa sta sotto è una persona, e questo evita che l’ordine diventi una negoziazione politica permanente.

Questo non vuol dire scrivere tutto da soli. Sviluppatori, designer, supporto clienti, vendite alimentano il backlog di continuo. Il PO raccoglie, filtra e ordina. La responsabilità ultima resta sua, perché senza un singolo punto di decisione l’ordine di priorità lo detta chi alza di più la voce nel meeting.

Come si scrive una voce

Una buona voce di backlog risponde a tre domande implicite: per chi, cosa, perché. La forma più diffusa è la user story (“Come [utente] voglio [azione] così che [beneficio]”), ma non è obbligatoria. Conta che chiunque la legga capisca il valore senza dover convocare l’autore.

Una voce dovrebbe contenere:

• Un titolo leggibile, non un codice criptico. “Permettere il pagamento con PayPal al checkout” batte “TASK-4471 integrazione gateway”.
• Il problema o il valore: perché vale la pena farlo. Se non sai rispondere, la voce non è pronta.
• Criteri di accettazione per le voci vicine alla cima: cosa rende il lavoro “fatto”.
• Una stima di massima, anche grezza (S/M/L o story point), almeno per le prossime due o tre iterazioni.

Le voci in fondo possono restare vaghe. È normale e perfino sano: dettagliare oggi una funzione che forse svilupperai tra otto mesi è tempo buttato. Il dettaglio cresce man mano che la voce risale verso l’alto.

Come si ordina: priorità, non simpatie

Ordinare è il lavoro vero del PM, e non si fa a sentimento. I tre assi che contano sono valore, sforzo e rischio. Una funzione che vale tanto e costa poco va in cima quasi sempre. Una che vale poco e costa molto può aspettare a oltranza.

Esistono metodi più strutturati. RICE (Reach, Impact, Confidence, Effort) assegna un punteggio numerico e aiuta a confrontare voci diverse. Ma anche un semplice valore-diviso-sforzo, fatto con onestà, è già meglio del criterio più comune negli uffici: fare prima quello che chiede chi urla più forte, di solito il commerciale con l’affare più grosso del trimestre.

Il punto non è il metodo perfetto. È avere un criterio dichiarato, così che quando qualcuno chiede “perché la mia richiesta è al quarantesimo posto?” tu possa rispondere con un ragionamento e non con un’alzata di spalle.

Backlog refinement: la manutenzione che nessuno ama

Il refinement (un tempo chiamato grooming) è l’attività ricorrente di tenere il backlog in salute. Non è una cerimonia solenne: di solito sono una o due ore a settimana in cui il team rivede le voci in arrivo, le chiarisce, le stima e, soprattutto, ne elimina.

Eliminare è la parte che quasi nessuno fa, ed è quella che salva il backlog. Una voce ferma da sei mesi sotto la cinquantesima posizione, che nessuno ha mai chiesto di promuovere, probabilmente non serve. Cancellarla non è una sconfitta: è igiene. Se l’idea è davvero buona, tornerà fuori da sola.

Un backlog su cui fai refinement regolare resta sotto controllo. Le voci in cima sono pronte per essere sviluppate, quelle in mezzo sono abbozzate, quelle in fondo sono titoli che si possono cancellare senza rimpianti. Questo è uno stato che si mantiene solo con costanza, non con una grande pulizia una volta l’anno.

Product backlog e sprint backlog non sono la stessa cosa

Confondere i due è uno degli errori più frequenti. Il product backlog è la lista completa e ordinata di tutto il possibile, di proprietà del PO, che evolve per tutta la vita del prodotto. Lo sprint backlog è il sottoinsieme che il team si impegna a completare in una singola iterazione (di solito una o due settimane), di proprietà del team di sviluppo, che si congela per la durata dello sprint.

In pratica: dal product backlog peschi le voci in cima, le porti nello sprint backlog all’inizio dell’iterazione, e per due settimane il team lavora su quelle. Il product backlog continua a vivere e a essere riordinato; lo sprint backlog resta fermo finché lo sprint non chiude.

Gli errori che lo rovinano

• Il backlog gonfio: centinaia di voci che nessuno legge. Se non lo puoi rivedere tutto in mezza giornata, sta diventando un archivio.
• Voci vaghe: “migliorare la UX”, “ottimizzare il backend”. Non si stimano, non si sviluppano, occupano spazio.
• Mai aggiornato: l’ordine riflette le priorità di tre trimestri fa. Un backlog non riordinato mente al team.
• Tutto in cima: quando ogni voce è “alta priorità”, nessuna lo è. La priorità ha senso solo se qualcosa sta sotto.

Domande frequenti

Quante voci dovrebbe avere un product backlog?
Non c’è un numero magico, ma una regola pratica: se non riesci a rileggerlo tutto in una sessione, è troppo lungo. Molti prodotti sani vivono bene con qualche decina di voci in cima ben curate e poche idee abbozzate sotto. La quantità non è un indicatore di salute, la pulizia sì.

Chi può aggiungere voci al backlog?
Chiunque può proporle: sviluppatori, supporto, vendite, utenti. Ma chi decide se e dove finiscono nell’ordine è il Product Owner o il PM. Questa separazione tra chi propone e chi decide è ciò che impedisce al backlog di trasformarsi in una lista di desideri ingestibile.

Ogni quanto va fatto il refinement?
Per la maggior parte dei team va bene una sessione settimanale di una o due ore. L’importante è la regolarità: un refinement costante mantiene il backlog sano con poco sforzo, mentre saltarlo per settimane costa una mezza giornata di archeologia per recuperarlo.

Un product backlog non è un documento che scrivi una volta e archivi. È più simile a un giardino: senza cura settimanale si riempie di erbacce, e a quel punto non distingui più cosa vale la pena coltivare. La differenza tra un PM che funziona e uno che annega nelle richieste, spesso, è tutta lì: nella disciplina noiosa di tenere quella lista corta, ordinata e onesta.