"Leggi l'analisi funzionale", "è scritto nel commento su jira", "perché non l'hai scritto?" sono alcune delle frasi che davano la cifra della comunicazione all'interno di un team di sviluppo. Incidentalmente (?) il team era composto da sotto-team di aziende diverse. Analisti e sviluppatori risultavano in conflitto e, come conseguenza, sembrava impossibile fare pianificazione o procedere in maniera costruttiva a risolvere difficoltà.
Entrambi i sotto gruppi si trinceravano dietro formalità (es. i documenti di analisi) o gergo tecnico che nascondevano una reciproca diffidenza.

La strategia utilizzata per superare lo stato delle cose ha visto il backlog come elemento centrale. Il backlog è stato usato, e strutturato, come puro strumento di comunicazione e non come elenco di cose da fare, o di specifiche.

Per evitare di aprire le discussioni a dettagli potenzialmente divisivi, se non irrilevanti, il backlog è stato generato, apposta, a livello alto, non particolarmente dettagliato.
Il motivo sta nell'obiettivo di migliorare la comunicazione. Il backlog è stato usato come un diversivo, un qualcosa di "terzo" che poteva essere attaccato senza attaccare le altre parti. Nell'arco di poche sessioni siamo riusciti a spostare la conversazione dalle persone al problema, trova do poi, in maniera quasi inconsapevole, lo spazio di collaborazione.

Si tratta di un talk frontale, partecipato perché il pubblico viene coinvolto continuamente con domande ed esempi.
La durata può essere personalizzata da 25' a 45'