A product manager recently asked me if one can get better at knowing whether things are easy or hard, and how long they will take. The good news is that with practice, you can help people estimate much better than they can estimate on their own.

Here's how.

Understand the problem you’re trying to solve

If you don’t understand the problem well enough, you’ll be blind to its potential complexities. Product managers are often in a better position than anyone else to understand the business problem at hand. Use your knowledge to make sure your team fully understand what needs to be solved.

Understand what’s involved in the proposed solution(s)

This can be the trickiest part for non-engineers, because the details of the solution may sometimes be pretty arcane. Here’s what you can do:

• Ask good questions about how things work, and what’s involved in the solution. Listen carefully to the answers. If they don’t make sense, ask for a higher-level explanation, or from a different person. Explain it back – that will make sure you’ve got it right and help you internalise it. Take good notes. Over time, you’ll start to see how the pieces interconnect, and what problems are similar to one another. This will get easier and easier.

• Don’t ask for an estimate for the whole solution. Break the solution down into pieces, estimate the size of each piece, and add them back together. In my experience, people can’t reliably estimate how long things will take beyond a few hours – so if the estimates are much bigger than this, break the pieces down into smaller and smaller chunks.

• Be the rubber duck!

• Offer to pair-program with a developer during the unit testing. You’ll get a really deep understanding of how the system works, and where the difficulties lie. Better still, if you write your tests before writing your code, your test suite provides a kind of score card for how close you are to a solution, and you’ll reduce time spent in QA.

Be aware of pitfalls and cognitive biases that lead to poor estimations

It's difficult to think through all the pieces for a complete solution to a problem. Instead, human beings tend to focus on the major parts, or the interesting parts, while ignoring the detail or the final 20% of a problem. Humans also tend to focus on the best case (everything goes right) and ignore all the things that might go wrong. While you may never know exactly what will go wrong, if you have a sense of some possible pitfalls, you can factor them into your estimate.

Here are some possible approaches:

• Start by asking out loud ‘what are the hidden traps, complications, edge cases, difficulties or things that could go wrong? When we did similar things in the past, how long did it end up taking? Were there surprise pitfalls that made it harder than we anticipated?’ Or run a full premortem. You’ll get much better estimates after this discussion.

• Use Planning Poker as an estimation approach: each person makes an estimate in isolation – this forces them to think things through, and avoids estimates being dominated by what was said first or most loudly. The discussion afterwards creates an informed consensus view, and provides immediate feedback for people whose estimates are wildly off.

• As a last resort: make an optimistic estimate and double it.

Continually learn from feedback

• Force yourself (or the project team) to make an estimate in advance, then during the project retrospective, compare the actual time taken to the estimated time. ‘We thought it was going to be X, but it turned out to be 2X’.

• If things take much longer than anticipated, ask how we could have predicted this in advance. That might help you avoid similar estimation mistakes in future.

• Notice if certain kinds of tasks tend to take longer than anticipated.

• Notice if certain people tend to be inaccurate, and give them feedback on this.

To sum it up:

Humans are full of biases that typically make us very bad at estimating[1]. You can help yourself and your team by:

• Deeply understanding the problem at hand, and the potential solutions (this might involve pair-programming with developers);

• Breaking down the problem into tasks that can be accurately estimated (each task taking no more than a few hours);

• Asking what potential problems might come up, then asking each person in your team to estimate in isolation, before discussing these estimates together;

• Continually learning from your estimates - giving people feedback if they are frequently inaccurate, and noticing any patterns of discrepencies as a team.

Note: This article was originally published at https://blog.gregdetre.co.uk/2015/09/07/oh-that-should-be-easy-maybe-a-few-minutes/