The Reasons Behind Why Planning Poker Works

Planning poker, sometimes called Scrum poker, is a technique in which a group of people assess how long a task will take from start to finish.

The technique works very well and here at ReQtest, we often use it ourselves when estimating the required development time for features we implement.

It is rather common to use planning poker when working Agile, but the technique works effectively even when the development is carried out in any other way. In this article we will develop a few ideas about why planning poker works.

The whole point of using planning poker is that as a process, it forces you to break down requirements into such small parts that it becomes possible to correctly estimate the time needed for each bit.

Anyone who has had builders or workers at home knows that estimating time is complicated. It is not possible to estimate time for tasks that are too big. It is possible to determine approximately how long it takes to replace a window but it is totally impossible to judge how long it would take to rebuild the house. The activities you estimate time for in planning poker must be so small that it is possible to estimate how long it will take to perform them.

In a 2006 experiment carried out by Simula research labs, a group of people were given the task of estimating time for implementing a requirements document that was designed in two different ways.

The difference was that one document was longer, but only because the text was spread over more pages, specifically 7 pages instead of just one page. Line spacing, margins and fonts were larger in the longer document. The group thought that the longer document would take considerably longer time to implement than the shorter one, even though the document contained exactly the same requirements.

The conclusion is that it is important to estimate small tasks one at a time. You can not estimate time for a full requirements document; it must be split into smaller parts.

In the same experiment a group estimated time for two documents where the difference was that one document contained many irrelevant details in addition to the requirements. The participants judged that the more complicated document would take twice as long to implement than the more concise. Again, the same requirement was interpreted in very different ways.

One conclusion is that it is important to write clear and concise requirements.

Usually when using planning poker, user stories are used as a basis because they force us to write concise and coherent requirements.

Us humans are easily affected by the other participants in a group.

In all groups there is always a formal or informal leader. If the leader speaks his estimate out loud for the rest of the group, they too will be affected by the leader’s view. We say that the idea is being ‘planted’ into the others in the group. If the leader says that a task will take 50 units of time on some scale, many of the participants will follow and agree.

Of course, it could also happen that some will disagree and come up with a very different estimate simply because they do not want to have the same opinion as the leader. This is the reasoning on which the rules of planning poker are based; every participant in planning poker flips and shows their cards at the same time, as this reduces the risk to be affected by each other.

To start using an excellent planning poker tool head over to which offers a completely free planning poker tool.

References we used in this article:

“How to avoidable impact from irrelevant and misleading information on your cost estimates”, Simula research labs estimation seminar, Norway, 2006