Planning Poker is a process used for estimation during the Sprint planning meeting, many times with actual cards rather than software. The various team members do their estimation of the tasks using Fibonacci numbering sequence, and after a couple of rounds of discussion, a finalization of the estimates are done, and these are converted into Sprint Backlog. However, for teams that are not very comfortable with Planning Poker, there can be several problems as dealing with Planning Poker. Some of these are:
- For somebody who is not comfortable dealing with Planning Poker, the concept of providing estimates in this manner can be confusing to people. Guidance, simulation and some hand-holding during early stages is essential
- There can be ego clashes if the estimates provided by team members vary widely, with the senior team members not being very comfortable if the estimates provided by the more junior ones are accepted. This needs careful handling
- Once numbers are presented in the meeting, then non-team members (including the product owner and senior stakeholders) will accept these numbers, and any further refinements start getting compared against these numbers
- Once somebody sees a number by somebody else, they start getting doubts over their numbers and if given a chance, many of the team members are willing to modify their numbers (just by doing some modifications in their head over the estimation). This can sometimes lead to a quick firming of the estimates towards a more accurate number, but can also lead to a herd mentality behavior
- Planning Poker is hard to do when the team is distributed, and needs more careful planning in terms of logistical coordination
- In Planning Poker, the assumption is that the team member has the required level of knowledge, but this can be inaccurate, what can happen in many cases is that the team has as much knowledge as is available, but there are many blank areas that are not yet filled, whether these be requirements from the product owner, or dependencies that are not known
- In some cases, the Product Owner is not satisfied by the varying estimates, and may want to put pressure to select the lower estimate so as to get more features in the current Sprint. The ScrumMaster needs to be pretty vigilant to avoid these scenarios
