Estimating Work That Depends on Another Team

Your team can size its own work well. Then a story needs an endpoint from the platform team, a schema change from data, or a design token that isn't built yet, and the estimate becomes a guess about someone else's calendar.

Separate the work from the wait

The most common mistake is folding the wait into the points. A story that takes your team two days of effort but sits blocked for three weeks is still a small story. Estimate the effort you'd spend if the dependency were already satisfied, and track the wait separately as a blocked state.

If you inflate the points to cover the wait, two things break: your velocity stops describing your team's capacity, and nobody can see how much delay dependencies actually cost you. That number is worth making visible.

Ask one question before you vote

Before estimating a dependent story, get an answer to: is the thing we need already agreed, or still to be negotiated?

• Agreed and specified: the contract exists, someone just has to build it. Estimate normally; the uncertainty is ordinary.
• Agreed in principle: you know roughly what you'll get. Estimate your side, and expect one round of rework when the shape differs.
• Not yet discussed: you're estimating a conversation, not a change. That isn't a story yet. It's a spike.

Most bad cross-team estimates come from treating the third case as the first.

Size the integration, not just your half

Teams routinely estimate the code they'll write and forget the code that connects it. Integration work (mapping fields, handling their error cases, adapting to their auth, writing the contract test) is real effort, and it scales with how different the other team's conventions are from yours.

When you vote, say out loud whether your number includes integration. Half the disagreements on dependent stories turn out to be two people estimating different scopes.

Make the dependency a first-class item

If the other team's work is substantial, it belongs on a board as its own item with its own owner and its own date, not as a footnote in your story's description. A dependency that exists only in your team's estimate is invisible to the people who could unblock it.

Don't commit to a sprint you can't finish

A story whose dependency lands "sometime in the next few weeks" should not be pulled into this sprint, whatever the estimate is. Plan it for the sprint after the dependency is confirmed, and fill the space with work you control. This costs you nothing in throughput and a great deal in credibility if you get it wrong.

Estimate what your team will do. Schedule around what other teams will do. Mixing the two produces numbers that describe neither.