In a recent post, I explained why we’re inherently bad at estimating, which is a major reason software projects often run late. But that doesn’t mean we can’t plan ahead for the longer term and manage expectations. Here are some techniques I’ve found effective for longer-term planning, even in the face of uncertainty:

Provide ranged forecasts 🌦, not fixed estimates

Over any reasonable period of time, providing likely delivery dates as a range rather than a fixed date is better. Doing so embraces the inherent variability and help stakeholders better appreciate uncertainty. Giving a fixed date, even when you all know it’s just an estimate, sets false expectations.

Don’t just estimate time ⏱, estimate confidence 💪

Along with estimating how long a task might take, assess how confident you are in that estimate. Is it something we’ve done before and know well? High confidence. Is it new, complex, or something we’ve never tackled before? Medium or Low confidence.Multiply time by confidence. For example, a “Small” task (e.g. 1-3 days) with “Low” confidence can be re-forecast as 1-7 days.

Longer term planning as risk management 🚨

Effective planning isn’t just about setting expectations on delivery, but managing risks over the project lifecycle. All those estimates which have come in as Large or with Medium-Low confidence? Those are your biggest risks and represent the most uncertainty. Identify risks early, identify potential mitigations, highlight those risks to stakeholders.

Account for Optimism Bias 🌈

Whilst you can’t completely mitigate against this, there are things you can do to be a bit less vulnerable. Involve the entire team in estimates, account for full end to end delivery (not just developer time) and factor in holidays, sickness and other factors that could impact delivery.Also, those ranged forecasts which provide a cumulative lowest range for all the work? Highly unlikely due to optimism bias! It’s probably best not to present the most optimistic forecast for this reason.

No silver bullet, but a better approach

These practices won’t eliminate uncertainty or guarantee perfect outcomes – there’s no silver bullet in longer term planning. However, I’ve found they help organisations plan more realistically, reducing the stress and frustration that often come with missed deadlines, and enabling more effective, adaptable strategies in the face of uncertainty.

Addressing performance issues is something many shy away from, often putting it off or hoping it will go away.

The sooner you do so, the more likely there’ll be a positive outcome for very everyone.

The longer you wait, the more difficult it becomes.

If it’s clear things aren’t working out then you need to act decisively. Don’t let it drag on.

It’s not only about the individual; it’s letting the whole team down and sets the standard for the level of performance considered acceptable.

“𝘞𝘦 𝘯𝘦𝘦𝘥 𝘰𝘶𝘳 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘦𝘳𝘴 𝘵𝘰 𝘣𝘦 𝘣𝘶𝘴𝘺 𝘤𝘰𝘥𝘪𝘯𝘨”

I still regularly come across this mindset. Not with any ill-intention. Developers aren’t cheap, so naturally you want them to be productive.

Whenever I do, I’m reminded of this meme (image created by Sebastian Hermida).

So this is a reminder that with software development…

𝗧𝘆𝗽𝗶𝗻𝗴 𝗶𝘀 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗯𝗼𝘁𝘁𝗹𝗲𝗻𝗲𝗰𝗸 🐵⌨

Development is about a lot more than just being heads down hammering out code – it’s about problem-solving, understanding user needs, designing scalable solutions, and ensuring that what’s built is truly valuable. Rushing to code without seeing the bigger picture leads to missed requirements & re-work, technical debt and buggy software.

It actually slows things down more than it speeds them up 🐌 🚧

Developers should be involved in the full end-to-end delivery process, not just the coding bit:

🔍 Understanding what we need to deliver, and why

🧪 Quality Assurance (you mean you didn’t test it before you threw it over the wall to QA?)

🚀 Shipping! Getting things out to customers before picking up new work

🤝 Collaborating with each other and other disciplines

Collaboration is a key one. When developers pair with each other or folks from other disciplines, it speeds up the process by reducing feedback loops and capturing issues early, and fosters shared understanding and ultimately, better solutions.

Having developers engaged more widely might seem counterintuitive if you’re focused on keeping them “busy” with coding, but it’s the best way to get the most out of their time.

Why are so many software projects late? Estimation (and how we use it) is often at the heart of it.

Humans are naturally optimistic. We overestimate how well things will go and underestimate the time required. It’s a well documented phenomenon:

🤞 Optimism Bias: Our tendency to believe things will go better than they likely will.

🗓️ Planning Fallacy: Underestimating time required, even when past experience tells us otherwise.

Secondly, even with careful planning, we can only account for what we know. As well as software development being inherently complex, as time progresses, unexpected factors always emerge: shifting priorities, new challenges, team changes – the “known unknowns” as Donald Rumsfeld infamously put it.

𝗖𝗮𝗻 𝘆𝗼𝘂 𝗴𝗲𝘁 𝗯𝗲𝘁𝘁𝗲𝗿 𝗮𝘁 𝗲𝘀𝘁𝗶𝗺𝗮𝘁𝗶𝗻𝗴?
Yes, we can avoid common pitfalls and improve our estimation practices. But they are still likely to be optimistic because of the reasons above.

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

– Hofstadter’s Law


𝗗𝗼𝗲𝘀 𝗔𝗴𝗶𝗹𝗲 𝘀𝗼𝗹𝘃𝗲 𝘁𝗵𝗶𝘀?
Agile embraces uncertainty, such as breaking down work into the smallest possible pieces and delivering value early and often. But it doesn’t eliminate the challenge of longer-term planning.


𝗗𝗼𝗻’𝘁 𝗯𝗼𝘁𝗵𝗲𝗿 𝗽𝗹𝗮𝗻𝗻𝗶𝗻𝗴 𝘁𝗵𝗲𝗻?
Not at all. Organisations need to plan. Without long-term planning, you can’t set realistic budgets, allocate resources & people, or prioritise efforts. The trick is learning how to plan effectively, even in the face of uncertainty.

In my next post, I’ll share how I’ve approached longer-term planning successfully.