Dipendenze tra team Scrum: come ridurle, gestirle meglio e migliorare la delivery

In teoria, un team Scrum ben impostato dovrebbe essere in grado di lavorare in autonomia e consegnare un incremento di valore “Done” a ogni Sprint. In pratica, però, soprattutto nelle aziende strutturate o in crescita, le cose funzionano raramente in modo così lineare.

Capita spesso che un team debba aspettare un altro team per completare una User Story. Oppure che lo sviluppo proceda più velocemente della validazione QA. O ancora che alcune attività restino bloccate perché dipendono da un reparto esterno, da un fornitore, da un team infrastrutturale o da una decisione non ancora presa.

Il risultato è noto: Sprint pieni di carryover, roadmap poco attendibili, frustrazione operativa, stakeholder che fanno fatica a fidarsi delle date e team che finiscono per lavorare “sempre tanto” ma con una percezione di avanzamento molto inferiore rispetto allo sforzo reale.

Il punto è che le dipendenze tra team Scrum non sono solo un tema organizzativo. Sono un tema di flusso, prevedibilità, qualità e valore rilasciato.

Ed è proprio qui che entra in gioco una gestione Agile più matura: non basta dire “stiamo lavorando in Scrum” per eliminare colli di bottiglia e attese. Serve un lavoro concreto su persone e processi, che considero centrali in ogni percorso di miglioramento operativo e trasformazione digitale.

In questo articolo vediamo:

• cosa si intende davvero per dipendenze tra team Scrum;

• perché rallentano la delivery e compromettono la pianificazione;

• come affrontarle in Sprint Planning e durante lo Sprint;

• come distinguere tra gestione tattica e miglioramento strutturale;

• alcuni esempi reali e operativi di Dependency Board e working agreement pronti da copiare.

Perché le dipendenze tra team sono un problema serio in Scrum

La Scrum Guide definisce gli Scrum Team come cross-functional e self-managing: in sostanza, team che possiedono internamente tutte le competenze necessarie per creare valore in ogni Sprint e che decidono autonomamente come organizzare il lavoro. Inoltre, l’intero Scrum Team è accountable per la creazione di un incremento utile e “Done” a ogni Sprint.

Quando però il lavoro dipende in modo significativo da altri team, accade l’opposto:

• il team perde autonomia;

• la pianificazione diventa meno affidabile;

• aumenta il lavoro “quasi finito” ma non completato;

• cresce il tempo di attesa tra un’attività e l’altra;

• peggiora la capacità di fare forecasting.

Dal punto di vista del business, questo si traduce in un problema molto concreto: il tempo che passa tra idea e valore rilasciato aumenta.

E quando il time-to-market si allunga, ne risentono tutti:

• il Product Owner, che fatica a costruire roadmap credibili;

• gli stakeholder, che vedono slittare le priorità;

• il team, che perde motivazione;

• il management, che percepisce Scrum come “meno efficace del previsto”.

Le dipendenze più frequenti nei team Scrum

Non tutte le dipendenze hanno la stessa natura. Per questo, il primo passo utile è saperle riconoscere.

1. Dipendenze tra team diversi

Sono le più visibili. Un team ha bisogno che un altro completi qualcosa prima di poter procedere. Alcuni esempi tipici:

• il team frontend aspetta API dal backend;

• il team applicativo aspetta configurazioni dal team DevOps;

• il team e-commerce aspetta un’integrazione dal team ERP;

• il team prodotto aspetta una validazione legale o compliance.

2. Dipendenze tra competenze all’interno del flusso

Sono più subdole ma altrettanto impattanti. Succede quando il team pianifica soprattutto la parte “di sviluppo” e sottostima attività essenziali come:

• test funzionali;

• QA;

• validazione UAT;

• design review;

• verifica analytics o tracking;

• pubblicazione e deployment.

In questi casi il team crede di aver completato tanto lavoro, ma in realtà ha completato solo una parte del flusso.

3. Dipendenze organizzative o strutturali

Sono quelle che si ripetono Sprint dopo Sprint. Di solito non dipendono da un singolo item, ma da come l’azienda è organizzata.

Ad esempio:

• team organizzati per componente e non per valore;

• QA centralizzata come funzione separata;

• competenze critiche concentrate in un solo reparto;

• architetture molto frammentate;

• processi approvativi esterni al team.

In questi casi il problema non è il singolo blocco. Il problema è il sistema.

Il vero rischio non è la dipendenza in sé, ma la falsa pianificazione

Una delle situazioni più dannose che vedo nei team è questa: durante lo Sprint Planning emerge una dipendenza, il team la riconosce, ma decide comunque di inserire lo stesso lavoro nello Sprint Backlog.

La logica, spesso implicita, è: “intanto lo prendiamo, poi vediamo”.

È qui che comincia il problema.

Se un item dipende da qualcosa che il team non controlla e che con buona probabilità non verrà risolto nei primi giorni dello Sprint, quel lavoro rischia di trasformarsi in:

• WIP in eccesso;

• aspettative disallineate;

• carryover a fine Sprint;

• percezione di scarso avanzamento.

In altre parole, non stai pianificando delivery: stai pianificando speranza.

Come gestire le dipendenze in Sprint Planning in modo realistico

Un approccio più efficace è molto più semplice di quanto sembri.

Quando emerge una dipendenza, la domanda corretta non è: “Possiamo comunque prendere questa storia?”

La domanda corretta è: “Siamo realisticamente in grado di completarla dentro lo Sprint?”

Se la risposta è no, allora nello Sprint non dovrebbe entrare l’intero item bloccato. Dovrebbero entrare invece le azioni necessarie a sbloccarlo.

Per esempio:

• contattare il team esterno;

• chiarire requisiti o aspetti tecnici;

• concordare la data di consegna;

• ottenere una decisione o approvazione;

• creare un’attività preparatoria che riduca il rischio;

• verificare alternative temporanee o workaround.

Questo approccio ha almeno tre vantaggi:

1. rende il piano più credibile;

2. evita di sovraccaricare lo Sprint con lavoro che non arriverà a Done;

3. restituisce al team una sensazione di controllo reale sul perimetro dello Sprint.

Le domande giuste da fare durante la pianificazione

Spesso le dipendenze non mancano: semplicemente non vengono esplicitate bene.

Chi facilita la pianificazione — Scrum Master, Product Owner o team lead — dovrebbe aiutare il team a portarle in superficie con domande molto concrete:

• Stiamo aspettando qualcuno per iniziare o completare questo item?

• Di chi abbiamo bisogno esattamente?

• Qual è l’ultima data utile entro cui ci serve il contributo esterno?

• Abbiamo già un referente chiaro?

• La dipendenza è tecnica, organizzativa o decisionale?

• Possiamo spezzare l’item in modo da completare almeno una parte davvero Done?

• Se questa dipendenza non si risolve, qual è l’impatto sullo Sprint Goal?

Queste domande hanno un valore enorme perché trasformano un blocco “vago” in un elemento pianificabile.

Caso tipico: sviluppo veloce, QA satura, Sprint sempre incompleti

Uno scenario molto comune nelle organizzazioni digitali è questo:

• il team di sviluppo ha alta capacità produttiva;

• la QA o il testing hanno capacità limitata;

• gli sviluppatori continuano a “finire codice”;

• il lavoro si accumula a valle;

• il team porta avanti molto, ma chiude poco.

Da fuori sembra che il problema sia la QA. In realtà, il problema è che il sistema sta ottimizzando il singolo reparto, non il flusso end-to-end.

In Scrum, il focus non dovrebbe essere: “ognuno completa il proprio task”.

Il focus dovrebbe essere: “il team completa un incremento Done”.

Se lo sviluppo produce più velocemente di quanto il sistema riesca a validare, testare e rilasciare, allora non stiamo migliorando la delivery. Stiamo solo aumentando l’inventario di lavoro incompleto.

Scrum.org insiste proprio sulla natura cross-funzionale del team: competenze diverse, responsabilità condivisa, collaborazione stretta e riduzione degli handoff sono elementi centrali di un team efficace.

La soluzione di breve periodo: gestire meglio le dipendenze

Nel breve periodo, non sempre è possibile ripensare l’intera organizzazione. Per questo serve anche una strategia tattica.

Le buone pratiche più utili sono queste:

Rendere visibili le dipendenze

Se non le vedi, non le puoi gestire. Una board dedicata, o una vista del backlog che evidenzi blocchi e owner, è già un primo salto di qualità.

Definire owner e date

Ogni dipendenza deve avere:

• un referente interno;

• un referente esterno;

• una data entro cui serve la risposta;

• una prossima azione chiara.

  
  

Ridurre il WIP

Più lavoro aperto significa più dipendenze simultanee e più complessità da coordinare. Anche in contesti Agile evoluti, ridurre il WIP resta una leva potentissima.

Creare working agreement tra team

Quando due team collaborano spesso, non conviene ogni volta “ricominciare da zero”. Conviene stabilire regole chiare su tempi, canali, formato delle richieste, priorità ed escalation.

Coinvolgere i ruoli giusti

Se la dipendenza è tecnica, la comunicazione deve avvenire principalmente tra persone tecniche. Lo Scrum Master facilita, ma non dovrebbe diventare un intermediario fisso che traduce contenuti complessi.

La soluzione di medio-lungo periodo: eliminare le dipendenze strutturali

Qui entra in gioco la parte più strategica.

Secondo LeSS, il punto non è solo “gestire le dipendenze”, ma eliminarne le cause profonde: architetture troppo complesse, team organizzati per silos, competenze frammentate, design organizzativo non orientato al valore.

Anche Scrum.org sottolinea che, nel lungo periodo, se le stesse dipendenze si ripetono costantemente, è probabile che sia necessario rivedere la definizione di prodotto e il modo in cui i team sono strutturati.

Dal punto di vista operativo, questo significa lavorare su alcune direttrici molto chiare:

• creare team più cross-funzionali;

• allargare le competenze chiave all’interno dei team;

• organizzare il lavoro per valore e non per componente;

• semplificare l’architettura dove possibile;

• distribuire meglio capacità critiche come QA, UX, analytics, DevOps.

Ken Rubin, in un approfondimento pubblicato da Mountain Goat Software, distingue tra dipendenze strutturali e dipendenze istanziate, spiegando che eliminare una dipendenza strutturale produce un beneficio moltiplicatore nel tempo, perché evita il ripetersi di molti blocchi futuri.

Dependency Board: esempio pratico pronto da copiare

Di seguito trovi un esempio semplice di Dependency Board che puoi usare in Jira, Notion, Excel, Trello o anche su una board fisica.

Struttura minima consigliata

Colonne:

1. Dipendenza identificata

2. Item / User Story collegata

3. Team o funzione esterna coinvolta

4. Tipo di dipendenza

5. Owner interno

6. Data ultima utile

7. Stato

8. Prossima azione

9. Escalation necessaria?

10. Note / rischio

Dipendenza identificata	Item collegato	Team esterno	Tipo	Owner interno	Data ultima utile	Stato	Prossima azione	Escalation	Note
Nuova API per checkout rateizzato	Story #245	Backend Payments	Tecnica	Luca	14/04	In attesa	Follow-up tecnico con BE	No	Senza API non parte il test end-to-end
Validazione legal per nuovo consenso marketing	Story #251	Legal	Decisionale	Martina	12/04	Bloccata	Inviare testo finale e reminder	Sì	Impatta go-live campagna
Configurazione ambiente staging	Story #248	DevOps	Infrastrutturale	Paolo	10/04	In corso	Verifica accessi e deploy window	No	Rischio slittamento test
Test regression su flusso carrello	Epic Sprint 18	QA shared services	Capacità	Elisa	15/04	A rischio	Ridurre scope o riallocare capacity	Sì	QA satura al 90%

Regole di utilizzo

Per far funzionare davvero questa board, servono alcune regole semplici:

• ogni dipendenza deve avere un owner;

• ogni dipendenza deve essere discussa almeno una volta a settimana;

• se la data ultima utile viene superata, deve scattare un’escalation chiara;

• nessuna dipendenza deve restare in board senza prossima azione.

  
  

Working agreement tra team: template pronto da copiare

Quando due team collaborano frequentemente, suggerisco sempre di formalizzare un working agreement leggero, molto pratico, da una pagina massimo.

Ecco un esempio.

Working Agreement tra Team Prodotto e Team DevOps

Obiettivo: Ridurre tempi di attesa, ambiguità e urgenze non pianificate nelle richieste di supporto tra Team Prodotto e Team DevOps.

Ambito: Deploy, configurazioni ambienti, accessi, log applicativi, supporto release e incidenti a impatto delivery.

Canale ufficiale di richiesta: Tutte le richieste devono essere inserite tramite ticket Jira nel progetto “DEVOPS-SUP”, con tag del team richiedente.

Informazioni minime richieste nel ticket

• contesto della richiesta;

• ambiente coinvolto;

• impatto business;

• priorità proposta;

• data entro cui serve il supporto;

• eventuali dipendenze collegate.

Tempi di risposta attesi

• richiesta standard: presa in carico entro 2 giorni lavorativi;

• richiesta urgente: presa in carico entro 4 ore lavorative, previa conferma del Product Owner;

• incident bloccante: attivazione immediata sul canale incident.

Gestione delle priorità: Le urgenze fuori pianificazione devono essere validate dal Product Owner del team richiedente e dal referente DevOps.

Rituale di allineamento: 15 minuti ogni martedì mattina per verificare richieste aperte, blocchi, rischi di Sprint e attività in scadenza.

Escalation: Se una richiesta supera la data ultima utile senza presa in carico:

1. reminder sul ticket;

2. messaggio sul canale condiviso;

3. escalation a responsabile di funzione / Delivery Manager.

Definizione di completamento: La richiesta è considerata chiusa solo quando:

• l’attività è eseguita;

• il team richiedente ha confermato l’esito;

• eventuale documentazione o output è stato allegato.

  
  

Working agreement Dev + QA: template pronto da copiare

Questo è utile quando il problema principale non è tra team diversi, ma tra fasi diverse dello stesso flusso.

Working Agreement tra sviluppo e QA

Obiettivo: Aumentare la percentuale di item “Done” a fine Sprint e ridurre il carryover.

Principi condivisi

• “Done” vale più di “sviluppato”.

• Nessun item si considera completato senza validazione concordata.

• Il team ottimizza il flusso complessivo, non il carico del singolo ruolo.

Regole operative

• durante lo Sprint Planning si stima anche il carico QA;

• non si inseriscono nuovi item se la capacità QA è già satura;

• gli sviluppatori forniscono evidenze minime di test prima del passaggio a QA;

• per gli item prioritari si definisce il test approach già in refinement;

• se la QA diventa il collo di bottiglia, il team ribilancia il lavoro prima di aprire nuovo WIP.

Indicatori da monitorare

• item completati vs item iniziati;

• carryover tra Sprint;

• tempo medio tra “dev done” e “QA done”;

• difetti emersi in test finale;

• percentuale di item che arrivano a Done entro lo Sprint.

Retrospettiva: Ogni Sprint si analizza almeno un item non completato per capire se la causa è stata:

• dipendenza esterna;

• capacità insufficiente;

• requisito ambiguo;

• handoff inefficiente;

• problema tecnico non emerso in refinement.

Un approccio concreto in 5 step per i prossimi 30 giorni

Se vuoi migliorare davvero la gestione delle dipendenze senza introdurre troppa complessità, questo è un piano molto concreto.

Step 1. Mappa le dipendenze ricorrenti

Per 2-3 Sprint, raccogli tutte le dipendenze che emergono. Non cercare subito la soluzione: prima misura il fenomeno.

Step 2. Separa dipendenze episodiche e strutturali

Quelle episodiche si gestiscono. Quelle strutturali si affrontano con interventi organizzativi.

Step 3. Introduci un Dependency Board

Anche semplice, anche minimale. L’importante è renderle visibili.

Step 4. Crea 1-2 working agreement

Non servono documenti lunghi. Servono accordi chiari con i team con cui collaborate più spesso.

Step 5. Porta il tema in retrospettiva con dati reali

Quante storie non sono arrivate a Done per dipendenze? Quali dipendenze si ripetono? Quali si possono rimuovere?

Quando serve un framework di scaling

Se più team lavorano sullo stesso prodotto, può essere utile introdurre momenti e pratiche di coordinamento più strutturate.

Nexus, ad esempio, nasce proprio per aiutare più team Scrum a lavorare da un unico Product Backlog verso un Integrated Increment, minimizzando problemi di dipendenza e integrazione.

In contesti enterprise più ampi, anche il PI Planning di SAFe viene usato per allineare team e stakeholder, identificare dipendenze e migliorare la collaborazione cross-team su orizzonti più lunghi rispetto al singolo Sprint.

Il punto, però, resta sempre lo stesso: il framework da solo non risolve il problema, se l’organizzazione continua a generare dipendenze strutturali.

Conclusioni

Le dipendenze tra team Scrum non sono un’anomalia. Sono una conseguenza abbastanza naturale della crescita organizzativa, della specializzazione e della complessità dei sistemi digitali.

Il problema nasce quando le consideriamo inevitabili e smettiamo di lavorarci.

Nel breve periodo, si possono gestire meglio con:

• visibilità;

• pianificazione realistica;

• working agreement;

• riduzione del WIP;

• maggiore collaborazione cross-funzionale.

Nel medio-lungo periodo, invece, bisogna fare un passo in più:

• ripensare i confini dei team;

• ridurre i silos;

• distribuire meglio le competenze;

• progettare il flusso attorno al valore, non attorno alle funzioni.

In altre parole: non basta far lavorare più persone sullo stesso backlog. Bisogna creare le condizioni perché il sistema nel suo complesso riesca a consegnare valore con continuità.

---

Domande Frequenti (FAQ)

Le dipendenze tra team in Scrum sono sempre un problema?

Non sempre, ma diventano un problema quando compromettono la capacità del team di consegnare un incremento Done a fine Sprint o quando rendono il piano poco attendibile. Se sono occasionali, si possono gestire. Se si ripetono costantemente, probabilmente c’è un problema strutturale da affrontare.

Come capisco se una dipendenza va gestita o eliminata?

Se compare una tantum, va gestita. Se compare Sprint dopo Sprint, coinvolge sempre gli stessi team o dipende dal modo in cui è organizzato il lavoro, allora va trattata come una dipendenza strutturale e ridotta a monte.

Cosa fare se il team di sviluppo finisce il lavoro ma la QA non riesce a stare al passo?

Vuol dire che stai ottimizzando una parte del flusso, non il risultato finale. In quel caso conviene rivedere capacità, WIP, Definition of Done, collaborazione tra ruoli e distribuzione delle competenze. L’obiettivo non è “scrivere più codice”, ma aumentare il numero di item davvero completati.