Planning Poker - effort estimation made easy

Estimating effort is very important for project planning. There are various ways of doing this, such as bottom-up, top-down or the Delphi method. Planning Poker can also help with effort estimation.

Planning Poker is a fun team consensus-building activity that uses relative effort estimates for user stories. Effort estimates are used to determine the scope and size of a user story. User stories are entries in the Product Backlog that reflect the customer's and end user's view of the product. Planning Poker has its origins in Scrum and can therefore also be called Scrum Poker. It is mainly used in agile software projects.

All developers, the client or, in the case of Scrum, the Product Owner and a neutral moderator or Scrum Master take part in the Planning Poker. As a rule, only team members who can comment on the task in the form of user stories should participate, and the group should not be larger than 10 people. The moderator is responsible for presenting the user stories and answering any questions that may arise.

The user stories are presented individually. There is now time for participants to ask questions. It is useful to set a clock so that the time frame is not overstretched. Then the participants estimate the relative amount of work. For this purpose, there are estimation cards with point values in Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21, etc., also called story points. These numbers are the sum of the previous numbers, e.g., 3 is made up of 1 and 2. This ever-increasing number is intended to illustrate the increasing uncertainty of guessing accuracy. With this in mind, the guessing cards are laid face down and when all participants have made their guesses, the cards are revealed. This gives three possibilities:
 

• Everyone agrees and the user story receives the corresponding story points. This means that all participants value the user story with the same effort.
• There is a disagreement, but the points are close enough so that the higher value is used for the effort of the user story.
• There is disagreement and the points are too far apart to agree without discussion. Then this is exactly what happens. Members should discuss why they have chosen these points. This can lead to changing opinions and a re-evaluation can take place. If the cards are turned over and there is agreement, the next user story is proceeded with. If agreement is not reached even after several attempts, the user story is put on hold. Either it is formulated and discussed again at the next meeting, or the user story is divided into smaller user stories, which might make it easier to decide on the next round. 

There is also a card that can initiate a coffee break. If this is laid by enough participants, a short break should be taken.

The process described above enables project planning that eliminates many uncertainties. By estimating the duration of the user stories, the time required for a Sprint and the resources needed can be better estimated. In this way, impediments can also be better estimated, and new insights can be added to those already available. Impediments are anything that hinders or delays the work. If they are known, they can be better managed. Depending on the type of obstacle, the team or the Scrum Master must ensure that it is resolved. Examples are unscheduled meetings, conflicts in the team or missing people.
Moderating the meeting ensures a structured process and prevents participants from getting lost in unnecessary discussions. Discussions that do not lead to a solution can be cut off, and the time frame set by the clock is also helpful. This prevents a single user story from going beyond the given framework and being put on hold if no agreement can be reached.
The fact that the points are given independently, so that the opinion cannot be influenced by others, ensures that people really do give their opinion. Often people are insecure and hold back their own opinion or conform to the opinion of others. But here you don't have the opportunity to do that, because you don't consciously discuss why you have classified something this way or that way until later. And then it's a matter of professional opinion, not a group dynamic that you have to bow to in order to be convinced. Every opinion is considered, heard and valued.
In this way, planning uncertainty can be reduced through the process.

Although Planning Poker has many advantages and can help the team to make decisions, there are also disadvantages that should not be hidden.
As mentioned at the beginning, it is important that team members who are familiar with user stories are involved in the process. Otherwise, you will have team members who have no experience at all and cannot really contribute. This can lead to a lack of consensus and wasted time because the moderator cannot end the discussion quickly enough. In addition to inexperience, it may also be that the user story is simply too large and needs to be reduced. It is therefore important to determine in advance how much time should be spent on a user story.
It can also be difficult to estimate the effort based on the numbers on the cards, as this is a fictitious size that cannot be easily converted into a real size. If you wanted to do this, you would have to do the same conversion for the whole project, otherwise there would be inconsistencies as similar things, just in a different Sprint, could be valued differently. So the team needs to learn how to work with the numbers on the cards.
Even if the points are given independently of each other, it can happen in the subsequent discussion that individual members feel compelled to change their minds in order to reach an agreement that they do not actually hold. However, this is also the case with many other methods, so it is difficult to avoid such problems.

Planning Poker is a fun way to estimate the effort required for a project. With the right estimate, decisions can be made early on that will steer the project in the right direction or even save it from imminent failure. It is also a relaxed form of discussion that can bring the team together and encourage a lively exchange of ideas.