TL; DR: They don’t. While estimates have value at the project planning level, there is no need for them to go any further. They provide no benefit to developers, but do carry significant risk.

The value and risk of estimates

Ask most developers what they think about estimates and, while you’ll certainly get a hearty discussion(/diatribe) out of it, I doubt you’ll hear much positive.

But most engineers when pressed will eventually accept that they are a necessary evil, for the simple fact that most people and businesses are date and resource driven, and developing software is an investment:

• If I have enough budget to pay for 30 days of development, I want to get the most value out of that; which may not be just that one “killer” new feature benefiting 100 people, but perhaps is 4 or 5 smaller enhancements benefiting 5000.

• Similarly, if I have a fixed deadline for go-live, I want to know what I can deliver before then, and what I can promise to my customers or investors.

Even if you’re going Agile, typically someone somewhere is going to want to have some overall idea of how long things are going to take and what can fit in, before they’re willing to give the project the nod. Some kind of estimate.

(At least in my experience of working in large enterprise software development working with risk-averse clients)

Now, we can make those estimates better, by making sure the right people are all involved, doing the appropriate amount of research, considering previous similar enhancements (bearing in mind non-transference).

But it’s important to recognise the essential attributes of those estimates:

• They are initial estimates - made at the point we know least
• They are guesswork - educated guesses, sure - but still guesswork
• They are built on a swathe of assumptions
• They don’t age well - as the software changes and enhancements are delivered
• They are made by people - with different experience and expectations

Sure, you can use them as an initial planning tool, but beyond that is where the unhealthiness starts.

Those initial inherently inaccurate estimates all too easy become a deadline, a promise, a contract, an anchor, an expectation, a judgement, and a prison. When faced with the reality of software development, and that inherent inaccuracy coming to light, then becoming a source of misery, anxiety, crunch, and burnout. Of deadlines being missed, developers quitting, and projects failing.

So how can we try to avoid this?

Culture can play a big part. Sending clear messages and setting healthy expectations from the top-down, but it’s all too easy for those messages to get lost, ignored, or unintentionally diluted:

• Using estimates as a planning tool and showing annoyance or having overdue process as things need to be pushed out of a sprint or timebox.
• A manager making a point not to condemn overruns, but praising things coming in under estimate (as that’s good right?), but without recognising the implicit message that gives.
• For the twin sisters of impostor syndrome and perfectionism to cause people to build unhealthy expectations and cages in their own heads. “Why am I always missing the estimate? Must work longer, must work harder…“

You can also repeat the exercise of estimating when it comes time to deliver the enhancement, creating a new, potentially (but probably not significantly) more accurate anchor for you to carry. (Though ask yourself, how often do you actually really make meaningful changes to your plans when they differ?)

But I think the solution can be simpler and healthier: Simply don’t show estimates to your developers.

Keep the estimates where they provide value, but draw the line there. That far, but no further!

Think about it: What do you want from me, your developer, picking up a new enhancement?

You want me to take my time to understand it, to break it down into manageable sub-tasks, to develop it, to test it, and to deliver it at a high level of quality. What part of that is benefiting from your initial estimate?

If you want your developers to deliver their best, and if you believe they are invested and motivated to do so, then what value is that overhanging anchor giving?

If anything it’s more likely to introduce problems:

• Teams unintenionally overcomitting, leading to missing delivery deadlines
• Developers rushing to meet those implicit / explicit perceived deadlines
  • Resulting in mistakes, bugs, loss of quality
  • Making themselves miserable / Burning themselves out in the process
• Or conversely, Parkinson's law: "work expanding so as to fill the time available for its completion"

In my opinion, breaking the split between what may be useful at a project planning level and what may be hurtful at a development level, would make things healthier for your developers and better overall.

But we need to know how the project is going?

Sure, I get it. Particularly for those long-term year spanning projects. And I’m not talking about stopping you (the project manager / lead).

All I’m talking about is removing those unhealthy and frankly unrealistic expectations from your developers.

You can still ask them to give you updates of how a task is going, though I would focus on asking them how complete they think it is, rather than how much time is left; and again treating that in a healthy manner.

You can then correlate that against your initial plans. If your developer says a task is 50% complete, but you thought it would be done by now, you can factor that into your plans. But the important thing is not to pass that expectation or pressure on.

It’s not the developers problem if things are overrunning. It’s yours, the project manager. That’s why you earn the big bucks. Either you trust your developers are doing their best, in which case it’s a planning problem, or you don’t, in which case you’ve got a morale/staffing problem, which you still shouldn’t solve by pressure.

In summary:

Estimates provide value, but also risk.

By limiting the use and visibility of those estimates, we can help minimise one aspect of the risk, while hopefully retaining the value.