Produttività

Backlog progetti: come decidere quali richieste diventano lavoro

Come registrare le richieste dei clienti, assegnare una priorità, rivedere il backlog e portare nel piano di progetto il lavoro approvato.

Flusia

|13 min di lettura

Illustrazione sulla gestione dei progetti con Gantt e Kanban

Un backlog di progetto è l'elenco ordinato di tutte le richieste, modifiche e idee che il tuo team potrebbe fare, ma su cui non si è ancora impegnato. Se ricevi richieste da più clienti, il backlog serve a separare tre cose che spesso finiscono nella stessa lista: il lavoro già promesso, le richieste in attesa di decisione e le idee senza priorità. In questa guida vedi come scrivere ogni richiesta, come scegliere cosa iniziare, come fare la revisione periodica (il cosiddetto grooming) e come comunicare a un cliente che la sua richiesta è rimandata.

In breve

Il backlog contiene solo richieste non ancora impegnate: il lavoro promesso va nel piano di progetto, le idee vaghe in una lista a parte.
Ogni richiesta ha bisogno di obiettivo, motivazione, referente, dipendenze e criterio di accettazione, altrimenti non si può valutare.
Per scegliere cosa iniziare confronta valore per il cliente, urgenza reale, impegno, dipendenze e rischio, sempre con le stesse domande.
Il grooming è una revisione periodica: si chiariscono, si scompongono, si riordinano e si eliminano le richieste.
Una richiesta rimandata si comunica con motivo, condizione per riconsiderarla e data della prossima revisione, mai con una scadenza inventata.

Indice

Cos'è un backlog di progetto e cosa non è
Come scrivere una richiesta nel backlog
Prioritizzare: come scegliere cosa iniziare
Grooming del backlog: come si svolge la revisione periodica
Come comunicare una richiesta rimandata
Backlog marketing: lo stesso metodo per campagne e contenuti
Errori comuni da evitare
Checklist del backlog progetti
Raccogliere le richieste dei clienti in un unico posto
Domande frequenti
Fonti

Cos'è un backlog di progetto e cosa non è

Nel mondo Scrum la Guida Scrum 2020 descrive il Product Backlog come una lista emergente e ordinata di ciò che serve per migliorare il prodotto, e lo Sprint Backlog come il lavoro che il team sceglie per l'iterazione in corso. In pratica, come riassume un confronto tra product, sprint e release backlog, il primo guarda al lungo periodo, il secondo all'immediato.

Non serve lavorare in Scrum per usare lo stesso principio. Se gestisci commesse per più clienti, il tuo backlog progetti è il punto in cui entrano tutte le richieste prima di diventare attività. La regola chiave è una: finché una richiesta è nel backlog, nessuno l'ha promessa.

Backlog, lavoro impegnato e idee: tre liste diverse

Il problema più comune è avere un'unica lista in cui convivono un bug segnalato ieri, una modifica già concordata con il cliente e un'idea emersa in riunione sei mesi fa. Tienile separate.

Lista	Cosa contiene	Chi decide	Cosa comunichi al cliente
Lavoro impegnato	Attività accettate, con responsabile e pianificazione	Responsabile del progetto, insieme al team	"È in lavorazione"
Backlog	Richieste chiare, valutabili, in attesa di priorità	Titolare o referente del backlog	"È registrata e verrà valutata il giorno X"
Idee senza priorità	Spunti incompleti, senza referente o motivazione	Nessuno, finché qualcuno non li completa	Di solito nulla: sono interne

Un'idea passa nel backlog solo quando ha i campi minimi compilati. Una richiesta del backlog passa nel lavoro impegnato solo quando qualcuno la sceglie in revisione e il team ha capacità per farla.

Backlog, pipeline commerciale e Kanban

Il backlog non è la pipeline di vendita. La pipeline segue le opportunità fino al contratto, come spiega la nostra guida al CRM Kanban per le opportunità. Il backlog interviene dopo, o in parallelo, quando un cliente già acquisito chiede modifiche, estensioni o correzioni.

Non è nemmeno la bacheca Kanban del team. La bacheca mostra come avanza il lavoro già deciso; il backlog è il filtro che decide cosa entra in bacheca. Se vuoi approfondire come organizzare poi quel lavoro, trovi i dettagli nella guida a Gantt, Kanban e task.

Come scrivere una richiesta nel backlog

Una richiesta scritta male non si può prioritizzare: nessuno sa quanto vale, quanto costa o quando è finita. La pagina di Scrum.org sul refinement ricorda che gli elementi nascono come idee vaghe e si precisano man mano che arrivano informazioni. Per questo conviene fissare un minimo sotto il quale una richiesta resta nella lista delle idee.

I campi minimi

Titolo: una frase che descrive il risultato, non l'attività ("Esportare i report mensili in PDF", non "Report").
Cliente e referente: chi ha chiesto e chi, lato cliente, può rispondere a domande e approvare.
Obiettivo: cosa deve essere possibile fare dopo.
Motivazione: perché serve, con il problema concreto che risolve.
Dipendenze: cosa deve esistere prima (un'altra attività, un dato, un accesso, un fornitore).
Criterio di accettazione: la condizione verificabile che dice quando la richiesta è completata. È il test che cliente e team concordano prima di iniziare.
Stima indicativa: piccola, media o grande, sufficiente per confrontare le richieste.
Data di prossima revisione: quando verrà rivalutata.

Alcuni team scrivono l'obiettivo come user story, cioè una frase nella forma "Come [tipo di utente], voglio [obiettivo] per [beneficio]". È utile perché obbliga a dichiarare chi beneficia del lavoro. Anche Unosquare indica tra gli elementi essenziali una descrizione chiara, il valore per il cliente o il business, la priorità e una stima dell'impegno.

Esempio ipotetico di richiesta completa

L'esempio che segue è ipotetico: azienda, cliente e dati sono inventati per mostrare il formato.

Campo	Contenuto
Titolo	Modulo di prenotazione con scelta della sede
Cliente e referente	Rete di studi tecnici "Alfa", referente: responsabile amministrativa
Obiettivo	I clienti finali scelgono la sede prima di fissare l'appuntamento
Motivazione	Oggi gli appuntamenti arrivano senza sede e la segreteria richiama ogni cliente per chiederla
Dipendenze	Elenco aggiornato delle sedi e degli orari, da ricevere dal cliente
Criterio di accettazione	Ogni prenotazione di prova inviata dal modulo riporta la sede scelta; la responsabile approva dopo 5 prove
Stima indicativa	Media
Revisione periodica	Rivalutata alla revisione del primo lunedì del mese

Nota il dettaglio della dipendenza: finché il cliente non invia l'elenco delle sedi, la richiesta resta nel backlog anche se è prioritaria. Iniziarla prima significherebbe lavorare su dati provvisori.

Prioritizzare: come scegliere cosa iniziare

Non ti serve un punteggio complicato. Ti serve un set di domande sempre uguale, così le decisioni sono confrontabili e spiegabili al cliente. Valuta ogni richiesta su cinque criteri.

Valore per il cliente e per l'azienda: quale problema risolve, per quante persone, quanto incide sul rapporto commerciale. Una correzione che blocca il lavoro quotidiano del cliente pesa più di un miglioramento estetico.
Urgenza reale: esiste una data esterna vera (un evento, una scadenza contrattuale concordata) o è solo fretta? Chiedi sempre cosa succede se la richiesta parte tra un mese.
Impegno: la stima indicativa. A parità di valore, la richiesta più piccola può partire prima; però non rimandare all'infinito quelle grandi e importanti, altrimenti il backlog si riempie di lavori facili e marginali.
Dipendenze: una richiesta che sblocca altre tre vale di più di quanto sembri. Una che dipende da dati mancanti non può partire, qualunque sia la sua priorità.
Rischio: cosa succede se non la fai, e cosa può andare storto se la fai di corsa.

Un metodo pratico in tre passaggi

Filtra: escludi le richieste senza criterio di accettazione o con dipendenze aperte. Non sono pronte.
Confronta a coppie: tra le richieste pronte, prendi le prime due e chiediti quale scegliere se potessi farne una sola. Ripeti fino ad avere un ordine.
Controlla la capacità: guarda quanto lavoro impegnato ha già il team e sposta nel lavoro impegnato solo quanto può realmente partire. Il resto rimane nel backlog, nell'ordine deciso.

Se più clienti chiedono la stessa cosa, raggruppa le richieste in un unico elemento e annota tutti i referenti: la priorità sale perché il valore è condiviso, ed eviti di sviluppare tre varianti dello stesso lavoro.

Grooming del backlog: come si svolge la revisione periodica

Il grooming, oggi chiamato più spesso refinement o affinamento, è la revisione con cui il backlog resta pulito e utilizzabile. La Guida Scrum lo descrive come l'attività continua di scomporre e definire meglio gli elementi, aggiungendo dettagli come descrizione, ordine e dimensione. Un articolo di Scrum.org sulla gestione del backlog insiste su due punti: deve essere un lavoro collaborativo e deve includere l'eliminazione degli elementi obsoleti, il passaggio più trascurato.

Come organizzare la riunione

Fissa una cadenza che il team riesce a rispettare, per esempio ogni due settimane o una volta al mese, in base a quante richieste ricevi.
Prepara la lista prima: il referente del backlog controlla che le nuove richieste abbiano i campi minimi e rimanda indietro quelle incomplete.
Invita le persone giuste: chi decide le priorità, chi stima il lavoro e, se serve, chi segue il cliente dal lato commerciale.
Chiarisci: per ogni richiesta nuova, verifica obiettivo e criterio di accettazione. Se manca un'informazione, assegna a qualcuno il compito di chiederla al referente del cliente.
Scomponi: una richiesta troppo grande diventa più richieste piccole, ognuna con il proprio criterio di accettazione.
Riordina: applica i cinque criteri e aggiorna l'ordine.
Elimina: chiudi le richieste superate, duplicate o ferme da troppe revisioni senza che nessuno le difenda, e avvisa il referente se la richiesta veniva da un cliente.
Registra le decisioni: per ogni richiesta rimandata annota il motivo e la data della prossima revisione.

Fissa una revisione periodica e assegna un referente alla lista.

Come comunicare una richiesta rimandata

Rimandare è normale; il problema nasce quando il cliente non sa che la sua richiesta è stata rimandata. Una comunicazione chiara protegge la relazione più di una promessa vaga.

Una buona risposta contiene quattro elementi:

Conferma: la richiesta è registrata e compresa (ripeti l'obiettivo con parole tue).
Motivo: perché non parte ora, per esempio una dipendenza aperta o altre attività già concordate.
Condizione: cosa la farebbe salire di priorità, come l'arrivo dei dati o una nuova esigenza del cliente.
Prossimo contatto: quando verrà rivalutata, non quando sarà consegnata.

Esempio ipotetico di messaggio:

Buongiorno, abbiamo registrato la richiesta del modulo di prenotazione con scelta della sede. Per partire ci serve l'elenco aggiornato delle sedi e degli orari: appena lo riceviamo, la valutiamo nella revisione del primo lunedì del mese e vi aggiorniamo sull'esito.

Evita frasi come "lo facciamo appena possibile" o date di consegna non verificate. Il tema della comunicazione verso gli stakeholder ha regole proprie, e una panoramica sulla gestione della qualità e della comunicazione di progetto aiuta a impostare un piano di comunicazione coerente.

Per chi segue il cliente dal lato commerciale è utile vedere lo storico delle richieste accanto ai contatti e alle opportunità: così chi parla con il cliente sa cosa è in lavorazione e cosa è in attesa. Trovi un metodo per organizzare queste informazioni nella guida su come organizzare la gestione clienti.

Backlog marketing: lo stesso metodo per campagne e contenuti

Le richieste arrivano anche al marketing: una landing per il commerciale, un contenuto per un cliente, un test su un canale. Il metodo non cambia, cambiano i campi. Per una campagna, un modello di organizzazione del marketing operativo indica obiettivo, target, messaggio, offerta, canali, landing, budget, contenuti, tracciamento, KPI, responsabile e revisione.

Mantieni la stessa separazione: le campagne approvate sono lavoro impegnato, le richieste chiare ma non scelte sono backlog, gli spunti senza obiettivo restano idee. Per invii di email o newsletter legati a una richiesta, la verifica delle impostazioni privacy e dei consensi spetta al referente privacy della tua azienda.

Errori comuni da evitare

Backlog infinito: se nessuno elimina, la lista diventa illeggibile e perde credibilità. Chiudere è una decisione, non un fallimento.
Richieste senza criterio di accettazione: il lavoro parte, ma nessuno sa quando finisce.
Priorità decise da chi insiste di più: usa sempre gli stessi criteri, così puoi spiegare ogni scelta.
Backlog trattato come promessa: se il cliente pensa che "registrato" significhi "in lavorazione", la delusione è garantita. Usa parole diverse per stati diversi.
Dipendenze ignorate: iniziare una richiesta bloccata produce lavoro da rifare.
Solo lavori facili: scegliere sempre le richieste piccole rimanda all'infinito quelle che contano di più.

Se le richieste dei clienti diventano commesse con fasi e costi, la guida su cosa deve fare un software gestione commesse ti aiuta a collegare il backlog alla pianificazione economica.

Checklist del backlog progetti

Usa questa lista prima di ogni revisione:

Raccogliere le richieste dei clienti in un unico posto

Raccogli le richieste con i form o dalle conversazioni con il cliente. Quando una richiesta è approvata, crea il task o il progetto e riportaci criteri di accettazione, responsabile e scadenza. Flusia include progetti, task, Gantt e Kanban da Quantum. Il portale cliente è incluso in Matrix.

Le funzioni disponibili dipendono dal piano e dagli eventuali add-on: controlla piani, fasce di utenti e condizioni aggiornate nella pagina prezzi di Flusia. Se vuoi valutare come raccogliere e prioritizzare le richieste del tuo team, conosci Flusia o richiedi una demo.

Domande frequenti

Che differenza c'è tra backlog e lista delle attività?

La lista delle attività contiene il lavoro già deciso, con responsabile e pianificazione. Il backlog contiene le richieste valutabili ma non ancora scelte. Tenerle separate ti permette di dire al cliente con precisione cosa è in lavorazione e cosa è in attesa.

Ogni quanto va fatto il grooming del backlog?

Non esiste una frequenza unica: scegli una cadenza che il team rispetta davvero, in base al volume di richieste. Molti team lavorano con revisioni ogni una o due settimane, altri mensili. Conta di più la regolarità della frequenza.

Chi deve gestire il backlog?

Serve una persona responsabile dell'ordine finale, anche se le decisioni si prendono insieme. In Scrum è il Product Owner; in un'azienda di servizi può essere il titolare, il responsabile operativo o il project manager.

Cosa faccio con le richieste che restano ferme per mesi?

Chiediti se qualcuno le difenderebbe ancora. Se no, chiudile e avvisa il referente del cliente; se il bisogno torna, la richiesta si può riaprire con informazioni aggiornate.

Fonti

Raccomandati

Condividi questo articolo

Scritto da