## Planning Poker

Estimating: the amount of time one thinks a specific task will take to complete.

A key part of agile development; it sounds simple, but in reality is easier said than done. So what techniques are there to improve how we estimate, and how can we make use of them?

I have read two articles by a guy called Kelly Waters, the Web Technology Director at IPC media:

The Secret to Delivering on Time

Planning Poker – Agile Estimating

Waters suggests that you estimate in points rather than in time.  This way you estimate the relative size of each feature (he says you should estimate in features rather than tasks – this is something we already do with our user stories), in comparison to other features.  He suggests using a number sequence like the Fibonacci sequence because this way the numbers get less precise as they get bigger, which builds a natural distribution curve.  He suggests estimating should be done as a team, and proposes Planning Poker as a good mechanism for this.

Planning Poker (no we’re not talking about the card game here), is an estimating technique done in groups.  The primary logic behind this is that two heads are better than one, three better than two, and so forth.  Certainly the result should be far more accurate if everyone involved has had an input, and more ideas will be generated through discussions.  Mountain Goat Software have designed software called Planning Poker which you can get for free (http://www.planningpoker.com).  With this you can use the same method to estimate in teams which are split across multiple locations via conference call.

Essentially then, everyone has a set of cards with numbers on (corresponding to whatever scale you choose).  Each feature is discussed within the team, and when everyone has individually decided on an estimate each person shows their cards to the group at the same time.  It is likely that there will be differences at this stage, so these are then discussed, then everyone votes again, repeating the process until (ideally) everyone agrees on the same number, or at the least there is only a small difference between them.  The team then moves on to the next feature.

Could this work for every team? It depends on the project. If you work on small projects for a short amount of time, it could potentially take too long to discuss estimates, to the extent that this in fact decreases productivity. More significantly, small projects mean small teams – most of the stuff we work on is in teams of four. It might be inefficient to set up PlanningPoker for this few people.  We should (and do) still discuss estimates, especially for user stories which require work by more than one developer.  However, when more than one person is involved with estimating a task it can get complicated.  While the two heads better than one theory makes a lot of sense, there is the danger that with this everything could end up becoming too broad and hence losing the accuracy it is meant to propagate.  With more than one person working on a task at once too there is further room for misjudging estimates and certainly more room for slipping.

Estimating in points rather than time has the advantage that it feels less like you are committing to a time period.  The tendency when estimating is to err on the side of caution and give yourself extra time “just in case”.  In technical projects this extra time can be invaluable as often tasks become complicated by outside factors.  But this is something which should not be considered at the time of estimation, but instead when analysing actuals – estimating should be done independently of any “what ifs”.  When using points rather than time it is less obvious how much time you are committing to.  However this also makes what should be a simple factor of time more abstract and could detract from the meaning.

While the Planning Poker technique is probably overkill, we can make use of some elements of it.  Specifically, the fact that team estimates should be done by the team and after discussion, rather than individuals.  But this discussion should not be extensive, because that encourages the tendency to add on that extra half day for contingency purposes, something which I firmly believe should be explained at the end of an iteration, rather than accounted for before.  With all of this in mind, we should employ the following principles when estimating:

• Go with your gut instinct.  In general you will know straight away roughly how long a task will take.  Obviously there will be exceptions to this, for example if you are having to use a new language, however –
• Ensure that as much preparation as possible is done in iteration 0, like learning new languages or skills, and all environments are set up beforehand to avoid the delays that invariably happen here interfering with the completion of tasks.
• When estimating a task that is to be completed by multiple people, they should all be involved in the estimate, but should each estimate their own part, then discuss any integration or dependencies with each other.  You should have a more accurate idea of how long a task will take you individually than the next person does.
• Make sure all off-project time is recorded accurately so that all time can be accounted for.
• Review your estimates after the task has been completed.  If you are consistently under or overestimating, try to work out why this is.