The planning fallacy appears especially frequently when estimating tasks in software development. However agile estimation methods like planning poker etc. don't seem to be designed to avoid this problem.
So what do you do to avoid the planning fallacy when estimating tasks or tickets in IT projects? Are there any product management methodologies or best practices which are designed to avoid this common fallacy?
Planning Poker is designed to use (or at least can be used so that it involves) a form of Reference Class Forecasting.
When estimating with planning poker, you can pick a sort of 'baseline' ticket that represents about 1 point of work, and then estimate all other tickets as being "about twice as hard" for 2 story points, or "probably 10 times as hard" for 13 story points, or "a lot easier" for 1/2 story point.
By estimating from a baseline ticket and only ever planning based on comparison to that one, all estimates become relative. This should eliminate a fairly large amount of bias; you aren't thinking in time but comparative size, which is something humans are much better at.
Then, to decide how far you can get, you look at the team's track record for "story points per sprint" and fill up to something comparable. If the team gets better, they keep estimating the same way, but the "story points per sprint" goes up, so the amount of work they take on grows as well, without ever having to re-calibrate.
This method works as long as you keep reminding people that story points are not measures of time, but of complexity to a reference point, and that they're not allowed to make the conversion between the two at any time. It stops working the moment you decide that a story point is an hour, or a day, or any other measure of time, as you'll immediately fall back into all the estimation traps that you (and the article) mentioned.
You cannot "avoid" bias. It's always there. You can only minimize it by estimating a task using multiple different methods and focusing on probabilistic estimates versus deterministic estimates. And, even then, you will only know how well you worked through the biases when you are able to compare your actuals with your planned values and you have a reasonably large number of comparison observations. This assumes you have a highly reliable method in tracking and controlling your actual values, and that is a huge assumption that is likely not very true.
As is true with all human biases, the more you think you have it under control, the more biased you are.
Per the “planning fallacy” Wikipedia entry:
The planning fallacy...is a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed.
Different agile frameworks use different metrics, but the commonly-used velocity and cumulatative flow metrics are the typical guardrails for mitigating planning bias. There are certainly other metrics, but I'll talk briefly about velocity because I think it most closely addresses the concern.
Velocity is a metric that looks at historical rates of delivery, and uses a moving average or other statistical functions to smooth perturbations. The velocity metric is probabilistic, and while it often works best with a baseline reference class to anchor the metric, in pragmatic usage it's actually less sensitive to that than one might think. The real determinant of how reliable velocity is as a predictive metric is the consistency of the estimation process.
The key to velocity's widely-accepted success in agile planning is a consistent estimation process. It actually matters very little whether the estimation process is optimistic, pessimistic, or ignores the reference class altogether, so long as the estimation process is applied similarly across iterations. Over a sufficient time window, a consistent estimation process will trend towards the sustainable rate of delivery.
While a consistent estimation process is essential to reliable forecasting, that doesn't mean your project's estimation process can't change or improve. The notable caveat here is that iterative or incremental improvements to the estimation process will create small perturbations in delivery rates, but will generally be small enough to be swallowed by the smoothing function.
As a related caveat, it's also possible to make radical changes (hopefully improvements!) to the estimation process. When that happens, you either need to discard historical data or apply a "fudge factor" to account for the changes in the methodology. This may lead to less forecasting reliability from the metric in the short term, but can often be worthwhile if it leads to higher sustained reliability in meeting forecasts.
It's not the estimating together part of planning poker that helps that much (although that can reduce individual biases). It's the velocity tracking part which lets you apply historical data to help with future estimates.
E.g., if in the previous sprint we tried to complete 50 points worth of work, but only finished 40, then our rate is probably closer to 40 than to 50.
Here's another example of using historical data to improve the accuracy of estimates (more complex in terms of data collection; also, it uses probability distributions).
Other methods that I've seen work:
Don't forget about the idea of estimate convergence (early estimates are way off, and they'll improve more and more as work progresses).
