How Long Will That Take? (How to Figure Out What Estimations Really Mean)

One of the first elements I got really interested about project management and scheduling was estimations. I remember doing some university papers about estimations many, many years ago. For some reason I was really interested about(1) estimating how much time doing some stuff takes and (2) how much time it really took.

(Writing that down makes me feel little stupid now that I think of this…)

Anyway, estimations. I wrote earlier about using points in estimations, but points have a tiny flaw: developers might feel that they don’t know what a “point” really means. Because of that, it can be useful to use term “day” instead of a point. (Or a “development day”). Nothing changes, except you just call points as “day” (or “development days”)

I know some “agile gurus” will argue that this is bad behavior, but what I like to do is to try things in practice and see what happens. With points, there’s also problems – and one problem is that it might be difficult to really understand points and their relative sizes.

So, now we can use a “day” in our estimates. One team (of 8 guys) could have a following estimates:

  • Level big boss, 20 days
  • 3 new weapons, 10 days
  • Exploding barrel, 5 days
  • Minimap, 8 days

Total of 43 days.

Now, after one calendar month of work they end up finishing things in following times:

  • Level big boss, 55 days
  • 3 new weapons, 30 days
  • Exploding barrel, 9 days
  • Minimap, 22 days

Total of 116 days spent in these, and they are finished. Team has used 160 days in this one month (after taking account all the breaks, sick days and so on), so their velocity (or “how much stuff they can do per month”) is 43 (development) days – the estimated work amount. The next month they finish stuff worth 51 (development) days, and 47 the month after that.

Now, after a few months we can see this team of 8 guys (who work 160 days per month) can finish tasks worth close to 47 (development) days. We can also calculate that estimation of 1 day equals to 3.40 real days (taking into account everything extra goes to meetings, hiring, discussions, bug fixing and so on).

I won’t go into detail about how the estimations could be done (that’s a topic for some other blog posts), and won’t go into detail about the possible problems of this style (and how they can be solved) in this blog post, but the basic idea is that you keep estimating tasks (and make sure that the relative sizes are proper: you want to make sure that your estimations are in line with each others) and then track the “total amount of days the team members have done”.

From these numbers it gets easier to give estimates. From these figures you can see what estimations really mean in a long run. For this team, a 5 day task really means close to 17 days of work (taking into account everything) on average.

Juuso Hietalahti


  1. I believe that one “man day” equals approximately 2.5 “woman days”.

  2. Eric: heh, indeed. Not to mention score points, experience points… ;)

    Jake: Man days sounds cool :)
    (although I think some companies use “man days” to mean “real days”…)

  3. When I estimate task I always take final value and multiply it by 3.1415. From my developer experience now I know that it works perfectly – you never take into consideration all the problems which you will have, discussions, web browsing and so on…

  4. I just use “man days” (yes I know it’s sexist and should be people days), and then map onto “real time”. Works fine as long as contingency is built in. For example, never map a man day of code onto a real day as you will not get 8 hours done when you’ve answered emails, browsed the web, talked to colleagues, deal with unexpected stuff etc.

  5. I guess the difference is it’s my ass on the line if my estimate is too short.

  6. I usually assume terrible unforeseen consequences will arise, and mull projects over for a long time before starting them, sometimes up to a year. When it comes time to actually implement ideas, I am usually far ahead of schedule.

  7. I would advise against using points in terms of game development progress. In every case that I have used the term points, it has meant percentage points for royalties on sales.

  8. That indeed can be a problem, and that’s why it is suggested to use words such as “development days” or “estimation days” to ensure that it wouldn’t get confusing.

  9. I think points would have been a lot less confusing than using days with two different meanings…

Comments are closed.