Lunedì mattina, 9:15. Tre project manager mi scrivono in contemporanea. Il cliente A vuole il prototipo entro giovedì. Il cliente B ha 'solo una piccola modifica' (spoiler: non è mai piccola). Il cliente C minaccia di non firmare la prossima tranche se non consegniamo la feature promessa sei settimane fa. Nel frattempo, il backlog ha 74 ticket che nessuno ha toccato dall'ultimo sprint planning. Questa è la realtà del 90% delle agenzie digitali. Non la teoria Agile dei convegni.
Perché il Tuo Backlog Sembra una Discarica
Il problema non è il volume di lavoro. È l'assenza di un criterio di prioritizzazione condiviso. Ogni PM difende il suo progetto, ogni cliente urla all'emergenza, e il lead dev naviga a vista seguendo ciò che sanguina di più. Le attività ad alto impatto senza scadenze urgenti affondano in fondo al backlog. Per sempre.
I Metodi Che Funzionano Davvero
MoSCoW: Semplice ma Quasi Sempre Mal Applicato
Must have, Should have, Could have, Won't have. Tutti lo conoscono. Quasi nessuno lo applica correttamente. La trappola classica: i clienti mettono tutto sotto Must have perché non capiscono che impegna la capacità del tuo sprint. La soluzione: validare il MoSCoW con un budget di punti. Hai 40 punti per sprint. Ogni Must have costa punti. Il cliente arbitra quando il budget si esaurisce. Questo cambia completamente la dinamica.
RICE: Il Framework Che Avrei Voluto Conoscere Prima
RICE sta per Reach x Impact x Confidence / Effort. Un punteggio numerico per ticket. Sembra freddo, ma elimina i dibattiti da ego nelle riunioni. Non devi più convincere il fondatore che la sua feature 'geniale' è in realtà un Could have. Il punteggio decide. Ho visto un team ridurre lo sprint planning da 2,5 ore a 45 minuti nell'arco di tre sprint dopo l'adozione del RICE.
Abbiamo smesso di litigare nelle riunioni il giorno in cui abbiamo deciso che comandava il punteggio RICE, non chi urlava di più. Il nostro burn rate è calato del 22% in due mesi. -- Direttore di produzione, agenzia e-commerce, Lione, 2025.
Capacità Reale: Il Numero Che Nessuno Calcola
Le agenzie pianificano sulla capacità teorica. 5 dev x 5 giorni x 8h = 200 ore di sprint. In pratica, dopo standup, code review e call non pianificate, si è tra 120 e 140 ore produttive. Tra il 30 e il 40% di perdita netta. Calcolare la velocity reale su sei sprint consecutivi non è opzionale. Strumenti come Clynt permettono di incrociare le ore registrate per progetto con la capacità pianificata, dando una lettura onesta del divario.
Prioritizzare Tra Progetti: La Sfida Vera delle Agenzie Multi-cliente
Se la risposta a 'chi decide?' è 'chi chiama di più', hai un problema di governance, non di metodologia. Una regola pratica: ponderare per margine lordo x rischio churn. I progetti a basso margine con clienti volatili scendono nella lista. Quelli ad alto margine con clienti strategici salgono. All'inizio fa male. Ma allinea le decisioni operative con la vera strategia dell'agenzia.
- Calcolare il margine lordo per progetto ogni settimana, non ogni trimestre
- Assegnare un punteggio di rischio churn (1-5) a ogni account cliente attivo
- Moltiplicare i due valori per ottenere un indice di priorità tra progetti
- Rivedere questo indice in comitato di direzione ogni due settimane
FAQ
Quale metodo di prioritizzazione è più adatto alle piccole agenzie con meno di 10 persone?
MoSCoW con budget di punti è il più accessibile per i team piccoli. Non richiede strumenti specifici e funziona in un semplice Notion o foglio di calcolo. La chiave è stabilire le regole con il cliente fin dal kick-off, non a progetto avviato.
Come convincere un cliente che la sua richiesta urgente non è prioritaria?
Mostragli il backlog prioritizzato con gli impatti di business quantificati. Un cliente razionale capisce che una feature che tocca 3 utenti aspetta dopo una correzione che impatta 800 ordini al giorno. Se il contratto prevede SLA chiari per livelli di urgenza, è ancora più semplice.
Il backlog interno dell'agenzia deve davvero essere separato da quello del cliente?
Sì, senza dubbi. Mescolare i due crea una gerarchia implicita in cui il lavoro per il cliente vince sempre. Le attività di miglioramento interno non avranno mai spazio se competono direttamente con le urgenze del cliente. Due spazi distinti, due rituali distinti.
Come misurare la velocity reale del team in un'agenzia multi-progetto?
Incrocia le ore effettivamente registrate sui ticket consegnati con la capacità pianificata su sei sprint consecutivi. Clynt consente di visualizzare questo scarto per progetto e per profilo, permettendo impegni futuri basati su dati reali anziché su intuizioni.