Scrum of scrums is back in the conversation. A LinkedIn collaborative thread on using scrum of scrums to manage dependencies drew contributions from dozens of practitioners, and Mike Cohn’s recent post on managing cross-team dependencies in sprint planning made the same point from the other side: when multiple teams ship one product, the dependencies are the product risk — and they need a dedicated place to surface. That place is the scrum of scrums. When it works.

What the meeting is actually for

A scrum of scrums is a short, regular sync of representatives from each team — not a management review. Its job is narrow: surface cross-team task dependencies, contention over shared resources or environments, and impediments that no single team can clear alone. Everything else — celebration, roadmap talk, general status — belongs somewhere cheaper.

The frameworks agree on the need even where they disagree on the shape: Nexus makes multi-team refinement mandatory precisely because, at scale, dependencies are inevitable; SAFe leans on PI planning to expose them early. Whatever the flavor, some forum has to answer one question every couple of days: who is about to block whom?

Why it degrades into status theater

Most failing scrum of scrums meetings die the same way. Each rep reads out what their team did — information nobody in the room can act on — while actual blockers hide in the last thirty seconds. The meeting is run from memory, so only the dependencies people happen to recall get discussed. And because nothing is written down against real work items, this week’s “we’ll sync offline” is next week’s slipped handoff. The result: a thirty-minute meeting that produces less coordination than a well-maintained board would produce in zero.

An agenda that earns its 15 minutes

Borrow the classic three questions, but scoped to inter-team effects. Each representative answers: What has my team finished that another team was waiting on? What will my team finish before the next sync that others should prepare for? What is blocking us that another team — or only this group — can unblock? Then the group works the blocker list, newest first, and every item leaves with an owner and a date. That’s the whole meeting. It’s the same discipline that makes a good sprint planning agenda work: questions that force decisions, not narration.

Run it from a live dependency map, not from memory

The highest-leverage fix is changing what’s on the screen. A scrum of scrums run from a live dependency view — every cross-team link and blocker, current as of this morning — stops being a recital and becomes triage. Jira already holds the raw material in issue links; the problem is that links are invisible at the moment of decision. (Our primer on cross-team dependencies covers how to model them cleanly in the first place.)

That visibility layer is exactly what Divim’s Dependency Manager & Map for Jira adds: a drag-and-drop map of links and blockers across projects, with the critical path highlighted — so the meeting opens on what actually blocks the release, not on who remembers what. Put it on the shared screen, walk the reddest chain first, and the meeting shortens itself.

Shrink the dependency surface before you manage it

The best scrum of scrums is the one with less to discuss. Two structural moves help. First, plan dependencies at the boundary where they’re created — during sprint planning, as Cohn argues — so teams sequence handoffs instead of discovering them mid-sprint; our sprint planning guide covers where that check belongs in the ceremony. Second, keep every team on the same cadence: identical sprint start and end dates make handoff points predictable and make “which sprint does this land in?” a question with one answer. Teams running SAFe-style trains do this with Enterprise Sprint Automation, bulk-creating aligned sprints across every board in a PI so the cadence is a given, not a negotiation.

Scrum of scrums isn’t broken as a pattern — it’s usually just starved of the one input it needs: a current, shared picture of who blocks whom. Feed it that picture, keep the agenda on decisions, and fifteen minutes twice a week will buy you more predictability than any scaling framework diagram ever did.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio