A stakeholder asks when the billing migration will be done. Someone on your team says "end of November," it goes into a slide, and from that moment the date is a promise. Six weeks later you are explaining why it moved, and the explanation is always true (a dependency slipped, an incident ate a week) and never helps. When you manage several teams, you also inherit the pattern at scale: every team gives you one date, you add them up, and you present the total as if it were a measurement.
The fix isn't better estimates. It's a different kind of answer: a range with a stated confidence, built from what your teams have actually delivered, with the assumptions written next to it. This post shows how to build one in an afternoon, how to read it, and how to talk about it with people who want a single number.
Why single dates fail
A date is a point forecast for something that has a spread. Work finishes earlier or later than planned for reasons nobody can see in advance, and the distribution is lopsided: a task can't finish before zero days, but it can take ten times longer than planned. Averages hide that, and a single date taken at the average will be missed about half the time by construction.
Three habits make it worse:
- Estimating in hours or days per task and summing. The sum inherits every optimistic guess and ignores waiting time, which is where most of the calendar time goes.
- Treating the date as a target. Once it is a target, people stop reporting the news that threatens it. Bad news arrives late, in one lump.
- Forecasting once. A forecast made in week one and never revisited is a guess with a project plan around it.
Daniel Vacanti's Actionable Agile Metrics for Predictability and his later When Will It Be Done? make the alternative case clearly: use the team's historical flow data to forecast, say the forecast as a probability, and refresh it as the work progresses. Nothing here requires special tooling.
Build the forecast from throughput
Throughput is the number of work items your team finishes per week. Not story points, not hours: items, counted when they are done. It works because you don't have to estimate anything. You just count what has already happened.
You need:
- Weekly throughput for the last 8–12 weeks. Pull it from your tracker: items moved to done, grouped by week. Exclude weeks that were not representative (a company shutdown) but write down that you did.
- The number of items remaining. Count them. If the work isn't broken down yet, see the split-rate step below.
- A way to resample. A spreadsheet works. A short script works too.
Say a team of seven delivered this over twelve weeks (a hypothetical example):
4, 6, 3, 5, 7, 2, 5, 4, 6, 5, 3, 5
That's 55 items, an average of about 4.6 a week. The remaining backlog is 40 items.
The naive forecast divides: 40 ÷ 4.6 is about 8.7 weeks, so "nine weeks." That is the 50/50 answer at best. To see the spread, run a Monte Carlo simulation: for each simulated week, pick one of the twelve historical weeks at random, add its throughput to the total, and repeat until you reach 40 items. Do that ten thousand times and count how many weeks each run took. On this data, one such run gave:
| Confidence | Weeks to finish 40 items |
|---|---|
| 50% | 9 |
| 85% | 10 |
| 95% | 11 |
Your numbers will differ slightly between runs; the shape won't. Read it as: "There is an 85% chance we finish within ten weeks and a 50% chance within nine." You can say that to a stakeholder in one breath.
Choose the confidence level on purpose
Which row you quote is a business decision, not a statistical one. Ask what a miss costs:
| If a miss means... | Quote roughly |
|---|---|
| Mild inconvenience, easy to re-plan | 50–70% |
| Another team's work is blocked, or a customer was told | 85% |
| A contractual or regulatory date | 95%, and plan the scope so you can drop items |
Say which level you chose and why. "I'm giving you the 85% date because the sales team has already told two customers" is a better conversation than a bare date, because it exposes the actual trade: a later promise is safer, an earlier one is riskier, and the stakeholder gets to choose with open eyes.
The narrow range is the trap
Notice how tight the table above is: one week between 50% and 85%. That comes from steady throughput and a fixed backlog. In practice the range is almost never the main risk. The main risk is that the backlog is bigger than you counted.
Work that is described at the level of "migrate billing" gets split into more items as the team learns what's in it. The ratio of items you end up with to items you counted at the start is the split rate, and you can measure it from your last two or three projects: items at the start versus items at the end.
Say your last three projects ended up with about 1.3 times the items anyone counted at kickoff. Then your 40 items are really about 52. Same simulation, same throughput:
| Confidence | 40 items | 52 items |
|---|---|---|
| 50% | 9 weeks | 12 weeks |
| 85% | 10 weeks | 13 weeks |
| 95% | 11 weeks | 14 weeks |
Three extra weeks from an assumption that has nothing to do with how fast the team works. This is the number to argue about with your teams, and it's the one an estimate-and-sum plan never surfaces. Write the split rate on the forecast so that it can be challenged.
Forecasting across several teams
At the associate level you rarely forecast one team's work. A few rules that keep this honest:
- Forecast each team separately, then combine the finish times, not the durations. If work in team B can't start until team A has delivered, B's start is A's finish at your chosen confidence, not the average.
- Don't multiply confidences casually. Two independent 85% forecasts that must both hold give about a 72% chance of both holding. If three things must all land, the odds drop further. For a cross-team plan, the combined confidence is lower than any single team's, and you should say so. The post on getting another team to deliver what you depend on covers the conversation to have with the team that owns the critical dependency.
- Look at where items wait. If most elapsed time is waiting for review, environments, or another team, no forecast method will help; you have a flow problem. Counting items by the state they are sitting in each week will show you.
Communicating it
People who want a date will push you for one. Some language that holds up:
- Lead with the decision. "We can commit to the week of December 15 with high confidence. If you need earlier, the date is December 1 at roughly 50%, and I'd want to cut scope to protect it."
- Show the assumptions on one line. "Based on the last 12 weeks of throughput, 52 items remaining including an expected 30% growth in scope, no planned time off beyond what's in the data."
- Say when you will update it. A fortnightly refresh turns a forecast into a running conversation. Stakeholders accept a moving range far better than a fixed date that moves once, late.
- Change the forecast out loud. When the range shifts, say what changed (throughput dropped, scope grew) and which of the two it was. That tells the stakeholder what they can influence.
What not to say is "it's just an estimate." It undermines the forecast and teaches the audience to ignore the range.
What to do this week
- Pull throughput for your teams for the last 8–12 weeks. Note any weeks you excluded.
- For one live project, count the remaining items and look up how the last two projects grew from kickoff to finish. That's your split rate.
- Run the simulation, and write the forecast as: the date at 50%, at 85%, the split rate you used, and the date you will refresh it.
- Next time someone asks "when?", answer with the range and a question: "Which level of confidence does this date need?"
The competency areas behind this, planning and forecasting, stakeholder communication, and managing across teams, are covered in the PTMA study guide, and the PTMA certification page shows how they are assessed.