Planning Poker requires the teams full attention, dedication, preparation and most of all time.

The first time a team uses planning poker there are often mixed feelings ranging from those who are almost speechless with the utmost regard for its simplicity and confidence building nature, to those who felt a bit awkward and felt that their professionalism was tainted by some silly game.

But every team who consistently take planning poker on as a core practise soon becomes accustomed to the benefits and begins to rely on it and takes every opportunity to spread the word.

Like any new practise though it can suffer when push comes to shove, the pressure is on and "we need those estimates yesterday". When a customer has an urgent change that needs to be delivered on a commercially and politically immovable date core practise is under threat.

Providing estimates in this kind of environment is a challenge to any team; there is pressure from the customer to just get on with it in some vain hope that it can all be finished in time. If you're using planning poker - stick to your guns but be careful. Planning poker takes time and this is because its the amalgamation of requirements low level discussion and estimating in one fell sweep. Even with time limits between rounds a consensus is difficult to reach if players are not comfortable. If there are significant questions unanswered with no simple articulation of an assumption to keep it at bay the game must continue until everyone is satisfied. That is one of planning poker's great strengths so any attempts to constrain it must be avoided.

So the team is under pressure and it finds its self with only an hour to run their planning poker game. Its doomed from the outset. The temptation to constrain the process is to great to resist and the first is to accept an unanswered question; we might hear statements like, "Ok so we don't know the answer to that but we have to come up with an estimate now." That's unlikely to come from a developer, but the product owner or project manager may feel the pressure to say such things. One of two things happens next:

1. Most likely is that an argument ensues about the constraint being applied to the teams beloved core practise. During the argument the moderator might not even notice that the egg timer has run dry and soon the hour is up.

2. Particularly if this has happened more than once the developers will know that the argument is futile and their reaction is instead to raise their estimates to account for the uncertainty. So, the team may come up with estimates but they will make the change appear impossible to achieve.

How can this be avoided?

The team could invite the customer to represent themselves - I've seen customers actually play - but that's not necessary. If the customer is there they can hopefully answer the questions and avoid the constraints being applied. This has a drawback though as with the customer present they are likely to be anxious about the numbers they are seeing develop out of the game and the time ticking away and they could begin to exert their own constraints.

The best approach is for the team to take its time and be deliberate - and not panic. Start the game with an open acknowledgement that an hour is not enough time to estimate all the features of the change. If nobody says this they will certainly be thinking it, so it's worth being open about it. At the end of the game there will be estimates for only some features. At this point if the partial estimate indicates that the change cannot be delivered in the time frame then it clearly needs de-scoping. Alternatively if the estimates are looking good its an easy sell to the customer to give the team more time to complete the exercise.

Play planning poker on-line at planningpoker.com