Before putting the hands on the keyboard and start development, it is necessary to have a plan. It is also necessary to have an idea how much certain tasks will take of your time.

It is possible fine to utilise a more scientific model like COCOMO II to create an estimate to lower the risk and the uncertainty level of a project. The drawback of such a model is that there has to be good understanding of how it works and for smaller projects the overhead of understanding and using such a big model might be unreasonable. But people already thought about this a long time ago.

During the 1950’s and 1960’s the Delphi Method had been developed to forecast the impact of technology on warfare. The basic idea of this method is that the judgement of a group of people is more accurate than the judgement of an individual person.

Especially in Agile Development it is not really possible to apply models like COCOMO, simply because the extent of the project is rather unclear at the beginning of it. A very popular technique for estimating that I’d like to introduce shortly is called “Planning Poker”, and it builds up a variation of the Delphi Method.

The key point of Planning Poker is that the “players” should not influence each other’s decisions. If a person says a time estimation, other people are likely to be influenced by that information and, consciously or subconsciously, change their own estimate to better fit the picture. To avoid this, all “players” have a set of cards with estimation numbers written on them. Everybody has to show their estimation at the same time to avoid the before mentioned problem.

Since estimations become more fuzzy the bigger they get, the cards hold the first 11 numbers of the Fibonacci sequence including zero plus optionally a Joker. The Joker can be used when the player is completely unsure for example. Given the estimates are done in working hours, instead of somebody saying a task takes 2 working days (16 hours) a decision has to be made whether it is safe to say the lower 13 hours are sufficient or the next available safer higher value of 21 hours has to be chosen. If an estimate is too big (and therefore too uncertain) it might also be worth discussing whether the task could be broken down into a couple of smaller tasks, which are potentially easier to estimate.

For each task or function that’s up for estimate, the Project Manager will give an introduction followed by a discussion to clear questions and uncertainties about the item on hand. Each player then lays a card representing their estimate face down on the table. When everybody has put down their estimate, the cards will be turned. People who are very far off the average are given the possibility to explain their decision after which a discussion might follow. The process might be repeated after a consensus is reached. It is also advised to set a time limitation for each discussion to not get stuck for too long in one round of poker.

Planning Poker has proven itself to be very useful in avoiding estimates that are too pessimistic or too optimistic as well as to avoid people being influenced by other’s decisions.

Image Credit: http://www.flickr.com/photos/cristic/369634461/