Estimates are difficult for developers and product owners

The best hack for improving estimation is first never giving a single number. Anyone asking for a single number, without context, doesn't know what they are doing; it's unlikely that their planning process is going to add any value. I think they call this being "not even wrong".

Instead you should be thinking in probability distributions. When someone asks for your P90 or P50 of project completion, you know they are a serious estimator, worth your time to give a good thoughtful answer. What is the date at which you would bet 90:10 that the project is finished? What about 99:1? And 1:99? Just that frameshift alone solves a lot of problems. The numbers actually have agreed-upon meaning, there is a straightforward way to see how bad an estimate really was, etc.

At the start of a project have people give estimates for a few different percentiles, and record them. I usually do it in bits, since there is some research that humans can't handle more than about 3 bits +/- for probabilistic reasoning. That would be 1:1, 2:1, 4:1, 8:1, and their reciprocals. Revisit the recorded estimates during the project retrospective.

You can make this as much of a game as you want. If you have play-money at your company or discretionary bonuses, it can turn into a market. But most of the benefit comes from playing against yourself, and getting out of the cognitive trap imposed by single number/date estimates.

This is what I do but I don't try to make it complicated with too many numbers. "2 weeks but there's a 10% chance something bad happens and it takes longer".

I have no problem if they just hear the "2 weeks" part. If they come complaining in 3 weeks I just say "we hit that 10%".

The other important thing is to update estimates. Update people as soon as you realise you hit the 10%. Or in a better case, in a week I might be able to say it's now "1% chance of taking more than a week".

One interesting angle for me is that I am seldom given complete specs or requirements when asked for an estimate. Of course you ask questions to try to determine key information that has not been specified but often the answers are not available or fully reliable.

So any estimate has to include uncertainty about _the scope of the work itself_ as well as the uncertainties involved in delivering the work.

The natural follow on question when you present a range as the answer to an estimate is: what would help you narrow this range? Sometimes it is "find out this thing about the state of the world" (how long will external team take to do their bit) but sometimes it is "provide better specs".

> The numbers actually have agreed-upon meaning

Theoretically, yes, but some managers go blank when given a hard concept like a probability distribution.

I've found that these incompetent folks (mostly in management as you say) really don't want to reveal their intellectual inferiority; they are desperate to hide it. If you started using this with your team, everyone adding value would benefit from the clarity, and the incompetent folks will just go along with it so as not to reveal their incompetence. They aren't adding value anyways, so it's fine if they fall behind.