Sprint Planning With No Historical Data: Capacity Checks vs. Probabilistic Forecasting

Last week I published a free sprint capacity calculator and shared it on r/scrum. The reception was — let’s call it educational. The top comment was “Please, don’t.” But buried in the pushback was a genuinely good debate with a commenter who knew his stuff, and it surfaced a question most agile content skips right past:

What do you do before the data exists?

Sprint Planning: The Two Schools of Sprint Planning

There are two legitimate schools of thought on Sprint Planning, and most arguments about agile tooling are really these two talking past each other.

The capacity school — the one most Fortune 500 delivery teams actually live in — says: figure out your available hours, subtract what you know you’ll lose (PTO, ceremonies, interrupt work), commit accordingly, then inspect and adapt. It’s estimation up front, correction in flight.

The flow school says: stop estimating entirely. Slice work into small, similar-sized pieces, measure how long items actually take to move from start to done (cycle time), and let statistics do the forecasting. With enough data, you can say “we finish 85% of items within 6 days” with real confidence — no planning poker required. This is the world of probabilistic forecasting, Monte Carlo simulation, and the #NoEstimates crowd.

Here’s the part both sides get right and neither likes to admit: the flow school has the better math, and the capacity school has the better starting point.

The Flow School’s Case Is Strong — With One Prerequisite

My r/scrum critic argued that statistical forecasting lets you reforecast “on a dime, for a dime” — cheaply and continuously — and he’s right. Once a team has roughly 20 completed stories of clean cycle-time data, you can model how work actually flows through the team, including the stuff capacity math never sees: wait times, handoff delays, context-switching tax. His sharpest point was that a 20% defect load doesn’t just cost 20% of capacity — the stop-start disruption on complex work adds its own tax on top. Twenty years of watching senior engineers get “quick question”-ed to death says he’s correct.

He’s also right that story points hide dynamics that matter. Thirteen one-point stories and one thirteen-point story look identical in a capacity model. In real life they behave nothing alike — the small slices ship, generate feedback, and let the team adapt scope; the big rock sits at 80% done until the last day of the sprint, radiating false confidence.

So if your team has clean flow data, small-sliced work, and the discipline to keep both — use probabilistic forecasting. Sincerely. It’s better.

Sprint Planning: Now Welcome to Day One

Here’s the scenario the flow school’s answer doesn’t cover, and it’s the scenario I’ve been handed more times than I can count across telecom and banking programs:

New project. New team — three contractors who started Monday, two internal folks pulled off other work. No cycle-time history, because the team didn’t exist last month. No story archive. A director who needs a commitment for the steering deck by Thursday. And two people already have PTO booked over the sprint.

“Collect 20 stories of cycle-time data first” is not an answer available to you. That data is 4–6 weeks away on a good team. Meanwhile, sprint one still has to be planned by somebody, Thursday still exists, and the honest options are: a number plucked from the air, or a number that at least accounts for the hours you demonstrably won’t have.

That’s the entire job of a capacity check. It’s not a forecasting model and shouldn’t pretend to be. It answers one question: given who’s actually here and what actually eats their time, how much less should we commit to than we’d like to? A rough answer to that question beats a rigorous answer to a question you can’t ask yet.

Sprint Planning, The Handoff Point: When to Graduate

The honest position isn’t capacity math forever — it’s capacity math until the data exists, then graduate. In practice:

Sprints 1–3: Capacity-based planning. Gross hours minus absences, ceremonies, and an interrupt buffer. Use a starting heuristic for points if you have no velocity. Commit conservatively — a new team that beats its commitment builds trust; one that misses builds a reputation. My calculator does this math in about a minute, but a spreadsheet works too. The tool isn’t the point; subtracting reality from optimism is the point.

Sprints 3–6: Start tracking two things per work item: start date and done date. That’s it. You’re quietly building the cycle-time dataset the flow school needs. Keep doing capacity checks for planning, but start comparing what the math predicted against what actually happened. The gap is your team’s personality showing up in numbers.

Sprint 6 and beyond: You now have 20+ completed items. If your organization lets you, shift the forecasting weight onto throughput and cycle time, slice work smaller, and let the capacity check shrink to what it always should have been — a PTO sanity check during planning week. If your organization still demands point commitments for the steering deck, run both and translate. That bilingual skill — flow math for the team, point commitments for the PMO — is half of what a good delivery lead does in a large org anyway.

Sprint Planning: What the Argument Is Actually About

The r/scrum debate was never really about my calculator. It’s about whether you plan for the team you have or the team the books describe. Flow forecasting assumes a team mature enough to slice small, track clean, and hold the discipline for months. Plenty of teams get there, and it’s worth getting there. But every one of them had a sprint one — staffed by strangers, measured by nothing, and due Thursday.

Plan the first sprints with the arithmetic you have. Collect the data as you go. Graduate when the data’s ready. And if someone tells you the arithmetic is beneath the state of the art, they’re probably right — and sprint one still has to be planned by Thursday.

If you’re newer to the methodology side of this, the agile project management overview covers the foundation. And credit where due: the r/scrum commenter who pushed back hardest made this a better article. That’s inspect-and-adapt working exactly as advertised.

Some links on John C’s Place are affiliate links where we are paid a small commission to support the site:  Our Other Platforms