Four Steps to Wrestle Back Control of Unpredictable Delivery and Low-Confidence Plans

It’s an old problem Agile never really solved.

No framework or methodology can magically fix low-confidence delivery plans. And while tooling helps — making work visible, establishing guardrails, setting policies — it’s never enough on its own.

Recently, during a consulting engagement, I found myself in a robust (not quite heated) discussion with a delivery manager and a program manager. We were deep in the weeds of how to configure the work management tool — who approves what, when, and how to lock it all down.

After 30 minutes, I paused and said:

“If we don’t build the right culture, it doesn’t matter how we configure the tool.”

To get predictability in delivery, you absolutely need to make the system visible and present meaningful data back for review. But none of it works without the human foundations in place.

So let’s be clear:
Everything in this blog post assumes that you're already working to build a respectful, psychologically safe environment. One where teams feel safe to be transparent about what’s really going on. One where people can speak up about blockers, challenges, and trade-offs — and where leaders genuinely listen and co-create ways of working fit for their context.

With that foundation in place, here are the four steps that will help you wrestle back control of unpredictable delivery and restore confidence in your plans.

Step 1: Shape and Slice the Work from the Top Down

Start with the big picture.

Before you can forecast anything, you need to make sense of the large initiative in front of you — whether it's called a program, a theme, or just a “project.” You have to start shaping and slicing it into smaller, more understandable parts.

Let’s call them features for the sake of this blog post. But they could be labelled epics, milestones, delivery phases — it doesn’t matter what the label is. What matters is that they’re small enough to reason about, but not so small that you lose the thread of the overall initiative.

This shaping and slicing is not clerical work — it’s facilitation.
It’s a thinking task, requiring people who know the domain:

• If it's a software delivery initiative, you need experienced engineers and architects.

• If it's a business problem, you need subject matter experts and delivery leads.

Slice too small, and you’ll end up with a fragmented mess that’s hard to sequence or track.
Slice too big, and you’ll lose your ability to deliver iteratively and release value incrementally.

So Step 1 is all about shaping the big unit of work into fit-for-purpose slices. Not too big, not too small. These slices — these features — become the foundation of your forecast.

Full overview of how burnups work in the video below.

Step 2: Estimate the Slices Using Top-Down Relative Estimation

Once you’ve shaped the work into coherent features, the next step is to estimate them — top down.

And here’s the key: do it relatively.

You’re not aiming for time-based precision. You're aiming to compare the size of one feature to another — using a simple scale like 10, 20, 30, 50 units of effort (often story points or similar). The focus is on proportion, not exactness.

Ask:

• “Is this feature about the same size as that one?”

• “Would this take twice the effort?”

• “Is it significantly bigger or smaller than what we’ve delivered before?”

And if something feels bigger than 50 units of effort?
That’s your prompt to slice it further — make it smaller, clearer, and more manageable.

When I was working on a large program at a telecommunications company, we had to estimate dozens and dozens of large features across an entire digitisation portfolio. We did it in one afternoon — three hours.
We used top-down relative estimation — no false precision, no debates over exact hours.
The result? A clear burn-up target for the entire portfolio that was good enough to put in front of the board. It told the story and set expectations, fast.

That’s the power of relative estimation.
It’s not about perfection — it’s about momentum, alignment, and shared understanding.

Of course, this kind of estimation only works if:

• You have people in the room who understand the domain, and

• You trust your collective judgement rather than chasing false certainty

So Step 1 is shaping.
Step 2 is sizing.
And together, they create a forecastable structure — without drowning in detail too soon.

Step 3: Face the Hardest Part — Team Capacity

Here’s where most forecasting models fall apart.

Capacity sounds simple, but it’s loaded — culturally, politically, emotionally. In fact, it’s one of the most challenging, misunderstood, and misused concepts in delivery planning.

Why?

Because when trust is low and traditional management thinking is still in play, practices like story points — meant to be safe and team-owned — quickly become coercive tools:

• “How many points is each person doing?”

• “Can we increase the velocity?”

• “Why isn’t this person tracking to plan?”

This isn’t bad intent. It’s simply a clash of paradigms.

For many managers, estimation has always meant control.
Agile flips that. It asks for trust, team autonomy, and a mindset of servant leadership — where teams create their own plans and managers support them, rather than the other way around.

It’s a big shift. And most organisations struggle with it.

So let’s be honest:

We’re not going to solve capacity in this blog post.
It’s too complex, too context-specific, and too culture-dependent.

But here's what I will say:
Story points are worth the effort — if management is willing to be coached.

Otherwise, even the best burn-up charts will fall apart under pressure from misuse and misinterpretation.

Without a psychologically safe, team-owned, and well-understood approach to capacity, your forecast will be fragile.
That’s why so few teams get to Step 4.

Step 4: Forecast with Burn-Up Charts — and Create a Learning Loop

If you’ve done the hard work — shaped the work, estimated it thoughtfully, and created the conditions for safe capacity planning — then burn-up forecasting becomes incredibly powerful.

Here’s how it works:

1. Take your total estimate — let’s say 100 story points.

2. Plot a burn-up chart showing cumulative completed work each sprint.

3. Use the chart to forecast completion dates, spot trends, and prompt healthy discussions.

But don’t treat it as a crystal ball.

The burn-up is not a prediction — it’s a learning loop.

Every sprint:

• The team refines its understanding of the work

• Capacity adjusts based on real-world factors

• Features get re-estimated or re-sliced if needed

And with that, the forecast evolves — in dialogue, not in silence.

It becomes a shared artifact that connects delivery to decision-making.
It builds confidence, not by promising certainty, but by showing how learning and progress are being managed transparently.

And If You Get All of This Right…

Let me say this clearly:

A well-designed burn-up forecast is one of the most powerful tools in Agile delivery.

I’m not just enthusiastic — I’m absolutely confident.

If you:

• Shape and slice work into manageable features

• Estimate those features with top-down relative sizing

• Build cultural safety around capacity and team planning

• Combine top-down targets with bottom-up refinement through stories

…then you unlock the ability to answer real questions:

• “How long will this take?”

• “What happens if we add or remove a feature?”

• “What impact will hiring more developers have?”

• “Are we on track, and if not, why?”

You’ll be able to answer these questions in seconds — not with guesswork, but with data grounded in team-led planning and real-time delivery insights.

But make no mistake — you only get this power if you do the hard work in Step 3.

And yes, embedding this approach usually requires experienced facilitation, strong coaching, and patience.
And yes, there’s more to say about getting work “ready” for estimation — but that’s for another post.

Download our free agile forecasting Excel here