Poker Planning in Scrum

Planning and systematic task discussions are essential components of teamwork within any project. When a team consists of two or three individuals, reaching an agreement on disputed matters is relatively straightforward. However, as the workgroup expands to 10, 20, or more members, opinions often diverge. Team members involved in software product development may assess the effort required for assigned tasks and their complexity differently. Poker Planning comes to the rescue in finding a ‘common denominator’. It’s a Scrum technique aimed at collaboratively resolving various tasks during the software product creation process.

Planning poker is a technique for assessing the complexity of tasks performed by a team. It was developed by James Grenning, one of the authors of the Agile Manifesto. Further development and popularization of the methodology were facilitated by Mike Cohn, who described it in his work ‘Agile Estimating and Planning.’

Planning poker helps to precisely assess the volume and complexity of tasks. All team members, including developers, testers, engineers, designers, analysts, and other project contributors, are involved in the estimation process. Team-based estimation yields an objective result. For instance, a developer might know how much time a task takes but could exaggerate its complexity to secure more time. Therefore, estimation results are always overseen by a manager who acts as a facilitator. No participants know each other’s opinions until the polling is complete. Their opinions are voiced simultaneously.

In Scrum, planning poker works as follows:

• Each participant receives a set of cards with number points or alternative symbols. Typically, this involves numbers from the Fibonacci sequence or various icons. For example, a ‘question mark’ signifies uncertainty, while a coffee cup or beer glass implies a need for a break in the discussion.
• Regardless of the symbols used, the smallest number is assigned to simple tasks. 0 represents the simplest task that should not be included in the plan. 1-3 denotes easy tasks, 5-13 signifies moderate complexity, 20-40 represents larger tasks, and 100 marks significant, large-scale tasks. Tasks labeled with the infinity symbol are considered epic in importance and scale.
• The client or product manager reads out the task. This is important to avoid the ‘broken telephone’ effect, where distorted information is passed from one participant to another.
• Participants are given time to contemplate. Then, they choose a card that corresponds to the task’s complexity and importance and place it face down on the table.
• Cards are revealed simultaneously. If there are significant differences in opinions, they are discussed with arguments presented for various solutions. If a participant estimates the task as the simplest, they should explain how they intend to complete it so quickly. Performers who assign the maximum scores to a task also provide reasons why they consider it so complex.
• An additional round of estimation is conducted. Based on the data collected, a final decision is made.

Before starting with the cards, the methodology for estimation is determined. You must decide whether you will assess the task’s complexity or the amount of time required for its completion?

Time	It is estimated how much time is needed to solve the problem.
Story Points	The complexity of the backlog products is evaluated.
T-shirt sizes	For task estimation, conditional ‘t-shirt sizes’ are used: XS, S, M, L, and XL.

In practice, it looks something like this:

• So, we have a task in front of us. How much time is needed for its completion?
• The participants of the game silently contemplate on what estimation to give to the task given by the client.
• Cards are revealed. Why do the opinions of participants A and B drastically differ from participant C? We discuss the issue!
• Cards are laid out again. An estimation for the task is given, taking into account the previous discussion. A collective decision is reached.

Advantages of the technique:

• All team members are involved in the estimation process.
• A consistent understanding of the task is formed within the working group through experience exchange among project participants.
• It helps to achieve consensus in determining task complexity.
• It eliminates the ‘anchoring effect.’ If one or more participants vocally state a specific time frame for task completion (‘I think it will take 6 days’), other performers unconsciously anchor to that number. That is, if someone determined for themselves that they can complete the task in 3 days, they will subconsciously inflate their estimation.

Use Cases of Planning Poker:

This technique is used in the development of software products within Scrum teams operating under an Agile methodology. The primary goal of Planning Poker is not to pinpoint an exact deadline for task completion, but to ensure that all team members understand the execution process equally accurately. The method is suitable for teams and tasks that have sufficient time to achieve consensus on disputed matters.

To make the technique more useful for the team, the following rules can be applied:

• Discussions should be productive. To avoid dragging them out, a two-minute timer is set. When it goes off, the right to speak moves to the next team member. This encourages everyone to express themselves concisely.
• Break discussions into smaller sessions. Large groups can also be divided into smaller subgroups. When remote team members are involved, Skype conferences with project management tools are used.
• As most managers strive for quicker completion, their voting can often be inefficient. However, they are more experienced compared to ordinary team members. If the estimation difference is insignificant, choose the larger one. In some cases, managers are given veto power over the team’s consensus.
• Participants participating in the poll should have an understanding of task complexity based on past practical experience.
• All estimates must be provided synchronously! Otherwise, participants will base their estimations on each other, minimizing planning objectivity. Set a timer on your phone or use a loud alarm.
• Do not disregard the ‘break’ card. Some people need time to rest.
• Hold meetings regularly, such as every two weeks or every other day, depending on the sprint duration. This helps keep all important tasks under control. If more time is needed for their completion, they are brought up for discussion again.

Application of LeaderTask for Project Management:

The Planning Poker technique is suitable for efficiently interacting teams. Different services and programs are used to organize communications between their participants and provide remote management for Scrum-method teams. One of these services is the LeaderTask application, which combines task manager, organizer, planner, and modern project management system functions.

This service replaces several popular planning applications, including Todoist or Trello. It helps efficiently allocate tasks among performers, plan the time for their completion, track the final result and effectiveness of each project participant. The application supports all the necessary functionality of flexible Agile methodologies, including electronic Kanban boards for a visual representation of tasks in the Scrum system.

The program includes a convenient chat for discussing current project matters. It can be used for messaging, exchanging voice messages, and commenting on attached documents. LeaderTask operates on all digital platforms, functions offline without an internet connection. It helps expedite task completion and team projects.

Conclusion

Planning Poker is based on chance, transforming the routine process of setting task deadlines into an engaging showdown among team members. It helps establish realistic deadlines and fosters a shared understanding of project complexity. Through the estimation process, the team finds the best solution for the task that is as close to implementation as possible. This method is best suited for agile teams implementing Scrum in its entirety.