Your team shipped almost everything on time this quarter. The roadmap still slipped.
So you call the client. The team did good work. One piece took longer than expected. The rest is nearly there. All true, and the client hears only one thing: the date moved.
Being right about the usual month doesn't make you right about the deadline.
For my last article, I showed that a single task has no finish date, only a range of likely ones. This time I asked the question that matters for a roadmap. If you use your team's own record to say how much it will finish next month, how often are you right?
I took three software teams with public records, between four and seven years each, and did what a careful lead would do at the start of a month. From what a team had finished in the month just gone, I forecast what it would finish in the month ahead. I made that forecast at every Monday in the records, treating each one as the start of a month, more than 800 times across the three teams.
Each forecast gave me two numbers. A safe number: what the team would finish at least, 85 times in 100. And a typical number, the usual month: what it would finish at least, 50 times in 100. In one month for one of the teams, the safe number was 44 tasks and the typical one 55. Higher certainty buys a smaller promise.
Then I checked every forecast against what the teams actually finished. The typical number was right. The teams beat it in half of their months, as they should. The safe number was not. A promise I would have bet on 85 times in 100 held three times in four, and when it broke, the team finished about 15 percent less than promised, up to almost 40 percent less in the smallest team.
One month in four, your client would still be waiting.
Once you've had to explain a moved date, you start padding. Your developer says August. Your lead says September. You tell the client October, because you've been here before.
When you turned August into October, how much confidence did you buy? A fixed margin can't tell you, because it knows nothing about how your team actually works.
You don't need to guess. Even a forecast that is too sure of itself knows what a fixed margin never can: how much a month can swing, and how often. Set that against the work still ahead and you can see how likely you are to keep the whole promise before you make it.
The honest version of October is October plus how sure you are you'll hit it. October at seven in ten is a different decision from October at nine in ten. Which one you need depends on what hangs on it: an internal target, a launch, a commitment to a client.
Your client needs a date they can plan around. If the chance of hitting October at seven in ten isn't good enough, agree on a later date or a smaller first version before they make commitments of their own. That conversation happens while they can still adjust, not when you're calling to explain a promise that already broke.
Before you promise the next date, ask your lead what chance the team has of hitting it.
I work out the chance behind your next roadmap date from the tasks your team has already finished, before you promise it. No workshop, no new estimate.
See the chance behind your roadmap
The three teams are the Vera C. Rubin Observatory's Data Management software, MongoDB's Evergreen system and Appcelerator Studio, from public records collected in the TAWOS dataset, the same projects as in Finish dates don't exist. Odds do. At every Monday of their records, between four and seven years per team, I forecast the next four weeks of finished work from the four weeks before, drawing those days at random, and compared the forecast with what happened: 807 forecasts in all. The safe number is the one the forecast puts 85 percent of outcomes at or above. The typical number is the one it puts half at or above. The example pair is one of MongoDB's months. The safe number held in 76, 74 and 71 percent of forecasts for the three teams, and when it broke, half the misses were larger than 13, 16 and 39 percent of the promise. The typical number was beaten in 53, 53 and 52 percent.
Forecasting from finished software work is described by Daniel Vacanti and Colleen Johnson. The numerical findings here come from my own analysis.