What Makes a Delivery Forecast Worth Believing?

Part 1 of 3

I've worked on a programme where the engineering team delivered, sprint after sprint, and the end date got harder to believe with every one of them.

Both things were true at once. That's the bit that took explaining.

The team was completing what we'd planned for the people we had. Sometimes we hit stretch goals. Sometimes stories crossed a sprint boundary, which everyone expected, because some of them held more than a sprint's worth of work and the subtasks were the smaller pieces. There was plenty of progress and nobody was making it up.

But a team that can deliver a sprint hasn't proved that a programme can hit a deadline. That's a different set of questions. How much work is left? How well do we understand it? Can the specialists we have finish it in the time we've got? Which decisions and dependencies need to land first? I think a lot of forecasting trouble starts when we ask the sprint report to answer questions it was never built for. (It's a very good sprint report. It's just not a crystal ball.)

Is ready for the next sprint the same as ready for the deadline?

Early on we had the opposite problem. We'd mobilised an engineering team, but there wasn't yet enough properly defined work to fill its capacity at sprint planning, so mid-sprint reviews pulled in more as specifications and designs arrived. That kept people moving. It also meant the resource plan assumed a volume of engineering activity that the preparation couldn't yet support.

Over the next few sprints that improved, then improved again, until we had enough ready work at planning, then more than enough, then stretch goals. If that improvement was all you were looking at, you'd have felt reassured. I did.

Meanwhile the people defining the work were being asked to do two jobs at once: prepare enough detail for the next sprint, and establish the remaining solution for the whole programme. The first was always urgent, so the first always won. We were very late into a substantial fixed-price programme before the full specification was close to done.

A backlog can be in lovely shape while the programme is still too poorly understood for the date it's been promised.

What exactly are we asking engineers to estimate?

An engineer can give you a useful estimate for a feature they understand, and they'll revise it when they learn something. What they can't do is make the undefined remainder disappear by being more precise about the part that's defined. An estimate of engineering effort doesn't, by itself, tell you how long the feature will wait for a business decision.

A forecast has to hold four things together: the effort, the capacity, the sequence, and whatever conditions let the work actually finish. Each is uncertain for its own reasons, and each needs a different fix. A requirement that needs investigation needs learning. A dependency nobody owns needs an owner. A business choice holding things up needs a decision. Asking the engineers to estimate again helps with one of those, and only one.

And at some point uncertainty stops being the right word. If the work we already understand can't fit into the capacity we have before the target date, we've stopped being uncertain and started doing arithmetic. Something has to give: scope, date, sequence, or capacity (where more people would actually help, which isn't always).

Image photo: Egor Kunovsky / Pexels

Where did the doubt show up first?

Not where you'd expect. Not feature by feature, where most things looked healthy and plenty looked green.

For me it was volume. No single outstanding question was hard. There were just a lot of them, and the client had decided to book a workshop three weeks out to get answers from the right senior stakeholders, which told us something: this wasn't a decision they could make today. That meant a delay of at least four weeks on a build we'd otherwise have finished, and the last five or ten per cent of the work couldn't happen for an uncomfortably long time. It pushed against everything behind it, testing included.

Where it showed up in black and white was the budget. As an illustrative example, say 65 per cent of the money spent against 55 per cent of the engineering complete. That gap doesn't prove an overrun by itself. It does mean I need to understand whether the remaining budget still covers the remaining work. Nobody's necessarily done anything wrong, but the gap is uncomfortable, and uncomfortable is usually the first honest signal you get.

Can a framework fix any of this?

The framework you choose won't fix it. I know leadership teams would quite like it to, because every new framework gets treated as a magic wand at some point. Agile will fix everything. SAFe will fix everything. If we just had a Kanban board, all of this would go away. They're tools. You adapt to them and you adapt them to you, but if chaos and inconsistency already live in the organisation, they'll simply move into the framework and make themselves at home.

What matters more is whether the commitments match the choice. If cost and time are fixed and scope is genuinely negotiable, iterative delivery is entirely reasonable. If the outcome is also tightly prescribed, the forecast needs to reflect real understanding of what it'll take, including an explicit line for what's still unknown. The trouble starts when we keep the freedom to decide later while treating the consequences of those decisions as already settled. A date planned around a solution we don't fully understand, resting on approvals whose timing nobody's established, is a hope with a calendar invite.

So what would make me believe it?

I'm usually the person who has to ask the boring project manager question. When will it be done? When can that decision be reached? When will I get that information? It's essential, because you can't plan without it, and it's uncomfortable, because the honest answer is often hard to calculate. That's why you ask the people who know, trust that they're giving you the best answer they can with what they've got, and never lean on them for a different one. I report the date leadership has agreed, as exactly that: this is the date we're working towards. If it isn't viable, my job is to go back and say so, and say why.

So when I look at a forecast now, I want to know what it's resting on. Which work is defined enough to estimate, and how is the rest represented? Does the capacity plan reflect the skills we need, or just a total number of hours? What has to be decided, by whom, and by when? How much time does it take to validate the whole thing? And what would make the date change?

That last one matters most. A date that stays put because nobody wants to reopen the conversation offers a different kind of reassurance, and usually a shorter-lived one.

Good sprint performance is useful evidence. It tells you something important about the team. It just can't tell you about everything it isn't measuring.

Before asking for a more accurate estimate, ask which uncertainty you're actually trying to shrink. It may not be anywhere near the engineering team.

Next: the feature that's been 98% complete for weeks, and why the last 2% is rarely the small part.

Cover photo: Kevin Mueller / Unsplash