"Tanto siamo agili, possiamo cambiare." Questa frase, ripetuta sprint dopo sprint, spesso nasconde lo scope creep in un progetto software: la difficoltà di prendere decisioni e mantenerle nel tempo.
Il problema è farlo ogni due settimane senza rendersi conto del costo reale. Ogni cambio di priorità ha un prezzo che si paga in lavoro buttato, stime che perdono di senso e team che smette di credere nel processo.
Cos'è davvero lo scope creep
Lo scope creep è l'espansione progressiva dei requisiti di un progetto. Non arriva tutto insieme. Arriva a piccole dosi:
"aggiungiamo anche questo campo",
"già che ci siamo integriamo anche questo sistema",
"il cliente ha chiesto una cosa in più, dovrebbe essere veloce".
Ogni richiesta singola sembra ragionevole. Ma la somma di molte richieste ragionevoli trasforma un progetto da tre mesi in uno da otto. E spesso nessuno riesce a spiegare dove sia finito il tempo.
La forma più insidiosa di scope creep è quella che si traveste da agilità. Agile significa poter cambiare direzione quando serve. Non significa cambiare idea continuamente senza una valutazione dell’impatto.
Pivot o indecisione? La differenza è misurabile
Un cambio di direzione sano ha tre caratteristiche:
- nasce da dati o feedback reali
- viene comunicato con trasparenza al team
- include una valutazione esplicita di tempi e costi
Quando invece:
- nasce da opinioni non validate
- viene presentato come “piccolo aggiustamento”
- non si valuta l’impatto sul lavoro già fatto
è navigazione a vista — e navigare a vista con un team di sviluppo è molto costoso.
Il costo reale del rework
Cambiare priorità a metà sprint non significa perdere solo il lavoro non completato.
Significa:
- codice già scritto che viene congelato o rimosso
- tempo pagato che non produce valore
- stime che perdono credibilità
- sviluppatori costretti a continui cambi di contesto, ognuno dei quali costa circa 23 minuti di recupero
Un team di quattro sviluppatori che butta via anche solo il 25-30% del lavoro di ogni sprint sta bruciando, di fatto, l’equivalente di uno sviluppatore a tempo pieno all’anno.
E quando le stime non funzionano, la pianificazione diventa impossibile.
L’effetto sul team (che poi diventa un costo)
Quando il lavoro viene sistematicamente cambiato o abbandonato, le persone smettono di investire energia.
Per realismo: perché impegnarsi al massimo su qualcosa che potrebbe essere scartato tra due settimane?
Il risultato è un team che lavora in modo difensivo, propone meno soluzioni e si limita a eseguire. Nel tempo, i profili migliori tendono a cercare contesti più stabili.
Dire "no" è parte del lavoro
Il ruolo del Product Owner è filtrare le richieste e stabilire cosa ha senso fare adesso.
Ogni sì è un impegno di risorse. E le risorse sono limitate.
Un buon Product Owner filtra, prioritizza e spiega perché qualcosa non entra nello sprint corrente. Questo richiede una visione chiara del prodotto. Senza visione, si finisce per inseguire l’ultima richiesta arrivata.
Regole pratiche per contenere lo scope creep
Definisci il risultato dello sprint, non solo i task
Alla fine dello sprint deve essere chiaro cosa può fare l’utente in più rispetto a prima. Questo rende più evidente cosa è fuori perimetro.
Usa un backlog separato per le nuove richieste
Le idee che arrivano durante lo sprint si raccolgono, ma non si discutono fino alla pianificazione successiva.
Rendi visibile il costo del cambio
Quando qualcuno propone di cambiare priorità, la risposta non è sì o no. È:
"Possiamo farlo, ma significa fermare X e spostare la consegna di Y."
Quando il costo è visibile, le decisioni migliorano.
Tratta lo sprint come un impegno
Per la durata dello sprint, il team lavora su quanto concordato. Questa stabilità è ciò che rende il lavoro prevedibile.
Valida prima di costruire
Molti cambi nascono da ipotesi non verificate. Un MVP ben definito riduce drasticamente la necessità di cambiare continuamente direzione.
L’agilità vera richiede disciplina
Il paradosso dell’agile è che richiede più disciplina, non meno. La possibilità di cambiare direzione funziona solo se si ha il metodo per farlo con consapevolezza.
Se le priorità cambiano ogni sprint e nessuno riesce a spiegare perché, il problema non è il framework agile. È l’assenza di una visione chiara e di regole che proteggano il lavoro del team.
L’agilità non è fare tutto. È fare le cose giuste, nel momento giusto, sapendo cosa si sta sacrificando.
Simone Giusti
Consulente software strategico
