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.