Sprint Collision Matrix: A 15‑Minute Pre‑Sprint Ritual to Spot, Prioritise and Assign Dependency Remediation

Most teams don't find out about their dependency problems during planning. They find out on day 6 of the sprint, when the backend engineer needs a config from the platform team that hasn't been touched in three weeks, and the person who owns it is on PTO. By then the estimate is wrong, the demo is at risk, and someone's drafting a Slack message that starts with "quick question but kind of urgent."

The frustrating part is that almost all of these collisions were visible before the sprint started. Nobody looked at them in a structured way. Planning meetings are built around filling capacity, not stress-testing the connections between work items. So the collisions stay invisible until they detonate.

This is a walkthrough of a small ritual — 15 to 30 minutes, run once before every sprint planning session — built around a fillable matrix that forces collisions into the open, ranks them, and puts a name next to each one. It's deliberately compact. If it takes longer than half an hour, you've turned it into a second planning meeting and it'll get skipped within a month.

What a "collision" actually is (and why sprint planning misses them)

A dependency collision isn't just "team A needs something from team B." That's a dependency, and everyone tracks those on some level. A collision is the specific moment where two or more pieces of work compete for the same scarce thing at the same time, or where one item's completion is gated by something outside the sprint's control.

The three that cause the most damage in practice:

1. 1
   Shared-resource collisions — two stories both need the one person who knows the payments integration, and both are scheduled for the same week.
2. 2
   Sequencing collisions — story B can't start until story A ships, but they were both pulled into the same sprint with the same due date because they "felt related."
3. 3
   External-gate collisions — the work depends on an approval, a vendor, a security review, or another team's release train that runs on a schedule you don't control.

Planning misses these because planning is a forward activity. You're looking at the backlog, pulling items, checking capacity. The collision only becomes obvious when you look sideways — across items, across teams, across the calendar. That sideways look is exactly what the pre-sprint review adds, and it's why running it before planning matters. Once people have emotionally committed to a sprint scope, they defend it. Do the collision review first and the scope conversation inherits the warnings.

The matrix itself

Here's the fillable structure. Keep it to one screen. If it spills onto a second page you're overthinking it.

Two scoring columns, both 1–3, nothing fancier. Likelihood is how probable it is that the collision actually bites this sprint. Blast radius is how much breaks if it does. Multiply for a score of 1–9. The reason the scale stays at 1–3 is that people can hold three options in their head and agree quickly. Give them a 1–5 or 1–10 scale and the review turns into a debate about whether something is a 6 or a 7, which is exactly the time-sink you're trying to avoid.

The Decision column only has four allowed values, and this is the part that makes the whole thing work:

1. 1
   Act now — do something before sprint planning starts (book the review, ping the vendor, lock the resource).
2. 2
   Descope — one of the colliding items comes out of the sprint.
3. 3
   Watch — leave it in, but assign a check-in trigger (a date, or a condition).
4. 4
   Accept — we know the risk, we're taking it on purpose, and it's written down.

Forcing every row into one of four decisions is what stops the review from producing a list of worries with no actions attached. A worry with no decision is just anxiety you've now documented.

A quick visual can help teams align on the one-screen constraint and the flow from scoring to decision.

The 15-minute run order

The ritual works best with the same small group each time: whoever's running planning, one or two senior ICs who know the codebase and the cross-team landscape, and ideally a rep from any team you depend on heavily. Five people max. More than that and you're back in meeting-load territory.

1. 1
   Pull the candidate backlog (2 min). Not the committed sprint — the candidate items you expect to pull. Everyone looks at the same list.
2. 2
   Surface collisions out loud (5 min). Go item by item and ask one question: "What does this touch that we don't fully control?" Write down every collision someone names. Don't score yet. Don't solve yet. Just capture.
3. 3
   Score likelihood and blast radius (3 min). Fast. Gut calls. If two people disagree, take the higher number and move on — you can always downgrade a Watch later.
4. 4
   Assign owners and decisions (4 min). Every row gets a name and one of the four decisions. The owner is the person who acts, not the person who caused the collision.
5. 5
   Carry Act-now items into planning as constraints (1 min). These aren't suggestions. They're facts the plan has to accommodate.

“

If two people disagree, take the higher number and move on — you can always downgrade a Watch later.

The whole thing is faster than it reads. After a team has run it three or four times, the collision-surfacing step gets quicker because people start pre-spotting the obvious ones on their own.

Decision heuristics that keep it honest

The scoring gets you a ranked list, but the score alone shouldn't dictate the decision. A few heuristics that hold up across a lot of teams:

A single shared specialist scored at 9 almost always means descope, not "work harder." If two high-blast items both need the one person who understands a subsystem, no amount of good intentions makes that person exist twice. This is the most common collision and the one teams most often try to will away. The related failure mode — keeping one person as the bottleneck for everything — is a capacity problem more than a sprint problem, and worth reading about in more depth at Stop Overcommitting: A Systematic Approach to Capacity Planning Across Your Project Portfolio.

External gates get "Act now" or they don't go in the sprint. A security review or vendor dependency that hasn't been booked isn't a Watch — it's a landmine. If nobody can commit to acting on it before the sprint starts, the honest move is to pull the item.

"Watch" needs a trigger or it's really "Accept." A watch with no date and no condition is just a row you'll re-read at the retro and feel bad about. Every Watch gets either a calendar date ("check Wednesday AM") or a condition ("if the pipeline PR isn't merged by standup Tuesday, cut SRCH-402").

When two teams both claim priority, the collision review is the wrong place to arbitrate. Note it, flag it, and push it to your actual prioritisation process. Don't let the 15-minute ritual balloon into a cross-team negotiation. If you don't have a clean way to settle those, the scoring-and-arbitration approach in Prioritize When Everyone Says It's Urgent is the right tool for that fight — not this one.

A real scenario

A 14-person product team at a mid-sized logistics SaaS company kept losing roughly one sprint in three to "surprise" blockers. Nothing catastrophic each time — a slipped dependency here, a shared engineer double-booked there — but their planned-vs-delivered ratio was sitting somewhere around 60–70%, and the sprint demos were getting apologetic.

The pattern, once they actually looked, was almost boringly consistent. About two-thirds of the misses traced back to three or four recurring collision types. The same platform-team dependency. The same one engineer who owned billing. The same security review that always took "just a couple days" and never did.

They started running the collision matrix for about 20 minutes before each planning session. First sprint, they caught a shared-specialist collision — score 9 — that would have blown up in week two, and descoped one item on purpose. Second sprint, they flagged a security review as Act-now and booked the slot three days early instead of finding out the queue was backed up mid-sprint.

Over the following quarter their planned-vs-delivered crept into the mid-80s and stayed there. No heroics, no reorg. They just stopped committing to work that had a knife pointed at it, and sprints got quieter. The most telling change wasn't the number — it was that the mid-sprint "quick but urgent" messages dropped off, because the urgent things had already been named on a Monday and given an owner.

When this actually makes sense

This ritual earns its keep when:

1. 1
   You have real cross-team dependencies — other teams, vendors, approvals, shared specialists.
2. 2
   Your sprints regularly deliver less than planned and the misses feel avoidable in hindsight.
3. 3
   The same collision types keep recurring and nobody's tracking them between sprints.

You have real cross-team dependencies — other teams, vendors, approvals, shared specialists. Your sprints regularly deliver less than planned and the misses feel avoidable in hindsight. The same collision types keep recurring and nobody's tracking them between sprints.

When it's a bad idea

This ritual is a bad idea in these situations:

1. 1
   Fully self-contained teams with no external dependencies don't need it. If nothing you build depends on anyone else, you're adding ceremony for its own sake.
2. 2
   Teams already drowning in process. If planning is already a two-hour slog, fix that first — bolting a collision review onto a broken planning process just makes the pain longer.
3. 3
   When leadership won't let you descope. The matrix is useless if every "Descope" decision gets overruled. If the answer to a score-9 collision is always "just make it work," you don't have a dependency problem, you have a capacity-and-authority problem, and this ritual won't fix it.

If the answer to a score-9 collision is always "just make it work," you don't have a dependency problem, you have a capacity-and-authority problem, and this ritual won't fix it.

Keeping it alive past sprint three

The honest failure mode isn't that the matrix doesn't work — it's that teams stop running it once things feel calmer, then get burned again two months later. A few things that help it stick:

1. 1
   Keep the same file, sprint over sprint. Don't start fresh each time. Recurring collisions become obvious when you can scroll back and see the same platform dependency appearing in six consecutive sprints. That's your signal to fix the root cause, not just remediate it again.
2. 2
   Review your "Accept" rows at the retro. Every accepted risk that actually bit you is a scoring lesson. Every one that didn't is a sign you were being too cautious.
3. 3
   Don't grow the matrix. The moment someone suggests adding a "notes" column and a "confidence" column and a RAG status, you're on the road to a form nobody fills in. Two scores, one owner, four decisions. That's the whole thing.

Where a shared workflow or tracking tool actually helps here isn't in any clever automation — it's simply having the matrix live somewhere the whole team can see it and where last sprint's version is one click away. A recurring collision that surfaces in a comment thread and disappears is a collision you'll troubleshoot from scratch every time. The same collision logged in one place, sprint after sprint, starts showing you where your real structural weaknesses are. That visibility is worth more than any single sprint's save.

The point of the whole exercise is small and specific: spend 15 minutes looking sideways at your work before you commit to it, so the things that would have surprised you in week two get a name, a number, and an owner on Monday morning instead.