In an agile software development process, estimation becomes extremely important, as over-estimating causes needless excess slack in a development sprint (or development iteration, depending on the terminology used), whereas under-estimating means that time becomes very tight as the sprint progresses.
One technique for estimating accurately is to play a game called dubbed planning poker. The whole team gathers together and discusses a set of requirements (often formulated as a user story), and are given a set of estimation cards.
The estimations are usually done based on ‘ideal man-days’, which means ‘the amount of work a single developer can do without any hindrances or delays’.
Developers are usually issued with cards zero (for ‘no effort’), 0.5 (half a day), 1, 2, 3, 5, 8, 13, 20 and a question mark. Higher estimations can be done by combining cards, but estimations of higher than 20 are usually symptomatic of a user story which needs to be split into smaller, more manageable user stories. The question mark card is played if a developer considers a task to be impossible to estimate, for example due to there not being enough information available, or the developer not having the required knowledge to accurately estimate a particular task.
The actual planning poker process begins by ensuring that everybody around the table fully understand the requirements of the software – what are the UI and IA requirements, what are the admin requirements, etc.
Once there is agreement that there is a common understanding about the requirements, the development team pick a card from their stack. At a given signal, the cards are turned over simultaneously. The ideal outcome of a round of planning poker is that all the cards say the same number (whether this is hours or man-days). If this happens, the number is recorded, and the team can move on to the next estimation task.
If there are discrepancies between the estimates, the outliers make their case; if one developer plays 3, three play 8, and one plays 13, for example, it might be that the developers playing 3 or 13 have more knowledge which might sway the other developers, or it might be that they have misunderstood something about the task at hand.
Planning poker continues until there is an agreement among the developers around how long a particular user story will take to implement.
The benefit of playing planning poker is that there is a low risk of misunderstandings: If one developer plays a card which deviates significantly from the estimates of the other developers, it usually means that there is a lack of information – the subsequent discussions around the topic usually resolves these misunderstandings, which causes higher accuracy in estimation.
-30-