I'm currently working on a game project. Since I don't have technical skills at all, sometimes it feels hard to doubt a programmer's estimation on a task is too much or not.

My solution is:

  1. Break down the stories to small tasks as possible so the time estimation becomes less vague.
  2. Look at the team to see if the estimation is overexaggerated or not.

Are there any better solutions for this? And also do you guys think there is a preferred way for programmers to communicate with PMs who don't know how to code?


I see two parts to your question, and they have very different answers:

  1. How can I get the most accurate estimates?

There's a huge amount of information on this question, including techniques like smaller tasks (as you correctly proposed), relative estimates, team estimates, planning poker, and more.

  1. How can I trust the estimates I am given, since I don't have the technical expertise to make my own estimates?

Comparing past estimates to actuals is the standard empirical approach, whether using a metric like velocity or just plain old "Dev A's estimates on average were 30% too low" bookkeeping. This general approach is most reliable, but it also takes good bookkeeping and enough time to gather data.

A complementary approach would be for you to participate (primarily as a listener/observer) in team estimation discussions.

In general, an estimate produced by a team discussion is likely to be more reliable than an estimate produced by a single dev. This is partly because any tendencies to under/over-estimate by a single dev will be washed out when the team comes to consensus (this is related to your proposed solution of looking to see the reactions of other devs).

It's also because in order to produce a team estimate, there typically needs to be a team discussion of the work that will be involved, so things are less likely to be overlooked or forgotten. This is why I like planning poker, especially in the case where different people offer different estimates and then explain their reasoning, followed by discussion.

Even though you don't have technical skills, you can probably follow the discussion at a high level, enough to follow the logic and understand the types of work that are being discussed, and get a sense for the completeness of the discussion.


Ask the developers for relative estimates rather than absolute ones. With relative estimation the development team put a points value on each deliverable item which measures its relative size and complexity, not its expected duration. You can then measure the actual number of points completed over a certain time (velocity). Velocity is an evidence-based measure of progress and you can track how it changes in future: accelerating or decelerating productivity. Previous estimates can also be used as a baseline for future ones.


First of all you need to understand what will be the consequence in case you receive under/overestimation.

As far as the estimation is provided by the team you need to have options to manage the situation.

For example: team says you that issue X will take them 5 days to be resolved. But some thirdparty will tell you that it could be done during few hours. Will your team figure out with it in few ours? - no. Team relies on their knowledge, rythm and occasionally they will try to make the issue done.

So my point is that you need:

0) you have to accept that each team has its own velocity/rythm (so there is no under/overestimation, only if you are trying to compare with other teams)

1) understand/measure team's velocity (at least 3 iterations should be taken into account to see the dynamic)

2) in case it's not suitable for the project rythm- start to dig into the root cause

3) in case 2 = true - make an appropriate changes

P.s.: I haven't heard "success stories" about PMs/teams collaboration in situation of mistrust.


I think in this particular case Planning Poker will help a lot in my opinion


  1. Each team member has to give estimates based on their experience or expertise
  2. All the estimates given by each team members revealed at once. hence no influence on each other.
  3. Each team member has to give reasons for their score.(Which also explains a lot about the task and its complexity)
  4. Most of the discussion is logical or based on previous experience but you can always question what you didn`t understand. This will improve your knowledge as well. and you will understand the risks more clearly.

Your Answer

