Planning Poker vs. Relative Methods: Which Agile Estimation Technique is Best for Your Team?

Product managers, project managers, and software developers would agree that estimation is difficult. In fact, many software developers claim that it is one of the most challenging aspects of the job.

Executive leadership and upper management often put a great deal of pressure on product development teams to ensure that estimates are as accurate as possible. However, it’s important to remember that estimation is just that—an estimation rather than a hard, concrete number.

Additionally, determining when and how to estimate in the first place is also a challenge. However, answering these questions is essential for launching, delivering, and deploying a successful project.

The good news is there are several estimation techniques in the world of agile project management. One common method is Planning Poker. However, like any technique, there are advantages and disadvantages to using it.

This article will explain more about what Planning Poker is, how it works, and the advantages and disadvantages of using it. We will also discuss Relative Mode and why teams should consider it as an alternative agile estimation method.


What is Planning Poker?

Planning poker is also referred to as Agile Poker. It is a group estimation technique often used by agile teams to estimate the amount of effort or relative size of development goals in software development.


Story Points and Planning Poker

The majority of development teams use story points to rate the amount of effort or work involved in a particular task or story. This is often expressed in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.


Here are the top reasons why the majority of teams use story points:

  • Story points represent the relative measurement of effort to deliver the story: the amount of work to do, the complexity of this work, and any risk associated with this story. Story points, however, do not measure the time spent on a story.
  • Estimating in story points is typically faster.
  • Specific days, dates, or hours typically don’t account for the day-to-day tasks or activities that aren’t related to the particular project. This includes answering emails, meetings, or other task management activities that occur throughout the day.
  • Since estimations are relative, they should involve comparing stories based on what’s known about the story itself and also considering teams' experience. The session should facilitate discussion to make sure all team members are on the same page about the scope of work. The relative weight should be similar for every member at the same seniority level (juniors, mid, or seniors).
  • Once the team has agreed on each story’s effort, it is easier to assign story points to development teams without any debate or surprises.

Planning Poker is a ‘gamified’ exercise to help estimate story point values. The moderator will take a story or task from the backlog, discuss the details, and then each team member will share his or her estimate. Some tasks or stories are easier to estimate than others. Sometimes team members will reach a consensus easily; other times, they will discuss and debate to reach an agreement.

Playing Planning Poker can be done both in-person and virtually. When the product owner or project manager runs through the list of each feature or backlog item, each team member shares their number individually (either expressed as the number of story points, depending on what the agile team uses as an estimation basis). Then, the estimates are discussed as a group.


Planning Poker: Advantages and Disadvantages

There are advantages and disadvantages to Planning Poker. One clear advantage is that each team member can "voice" his or her estimates, which potentially encourages group discussion and collaboration. It also allows team members to feel more committed to the project plan.

Although Planning Poker might seem like a fun way to estimate effort and work as a group, the process of the “game” or technique itself isn’t entirely intuitive. It can take a significant amount of time to figure out how to play the game in the first place, nevermind coming up with accurate estimates.

Furthermore, it isn’t completely relative, and it can make the process of using story points more difficult and complex. In Planning Poker, items are estimated one by one, and each of them should be compared to a baseline. But the problem is that session participants often try to figure out how many times bigger the given item is and here is where the estimation fails. We end up with estimations in fixed time intervals and the real idea of relative estimation is to compare items against each other. That’s why Planning Poker is very often recommended for teams with bigger story points experience.


Introducing An Alternative Estimation Method: Relative Mode

Relative Mode is another agile estimation method that can better support the process of team estimation.

Relative Methods, also referred to as the Magic Estimation Games, are perfect for making pretty rough, relative estimations of many issues, and a small number of issues with detailed discussion. It consists of estimating items or user stories, not separately, but by comparing or grouping the items of equivalent difficulty or effort.


No matter if you work in a team new to estimates but also for mature teams with greater experience in estimating that want to speed up the estimation process. This method is for your team if you prefer a visual representation and interaction.


Top 4 Advantages of Using Relative Methods

Now that you have a better understanding of Relative Mode and how to use it in Agile Poker for Jira, here are some advantages of using it as an alternative agile estimation method:

1. It is visual and interactive, making it easier and a better solution for remote or distributed teams. Due to its visual nature, participants can see the tasks or issues to estimate relative to one another. They can compare items or issues by placing them in their respective columns.

2. It is easier to set up, moderate, and manage. Product Managers, Product Owners, Scrum Masters, or Project Managers can set up an estimation “board” by using a tool that supports Relative Mode in minutes. The estimation can be done in a fraction of the time it takes to figure out and explain Planning Poker to a team.

Unlike Planning Poker, Relative Methods are great for teams that have a low to moderate experience in Story Points estimation since team members don’t need to think of estimation values but only compare one issue to another.

Furthermore, the session facilitator can easily move the tasks or issues into a column for estimation, collect estimates from the team, save them, and move onto the next—and all in one view.

3. It is productive and produces results faster. Again, Relative Mode engages the entire team because of its visual and interactive nature, ensuring a high participation level. Relative Mode enables team members to submit and share their estimates, reducing the need to push them for a response and awkward silences that fill a meeting room or Zoom call. Relative Mode is effective at producing and driving fairly accurate estimates and in less time.



Relative Mode is effective at producing and driving fairly accurate estimates and in less time. It is easier and more efficient than scrambling to write down estimates or taking notes in a separate document while simultaneously leading the Relative Mode session.

4. It is more collaborative. By saving time and effort from setting up and explaining a “game” of Planning Poker, Relative Mode is more straightforward. The session moderator selects an issue or task to estimate, each participant or team member submits his or her response, and the team reaches a consensus. If they do not reach an agreement, they can discuss and deliberate accordingly and re-estimate them if needed.

Although Relative Mode doesn’t speed up the process or reduce the time spent on estimating story points, it does reduce the amount of time spent on discussing the logistics of the game, making it an easier and more productive estimation method overall.


Agile Estimation is a Team Effort

Agile estimation should involve the entire team—product owners, developers, designers, testers, etc. It is critical to ensure accurate estimates as each team member has a different perspective on the product and the work required to deliver a user story.

Many team members often think that estimation is just for the product or development team because estimating only involves the development team’s time. However, this isn’t correct. All the core functional areas of designing, developing, and bringing a product to market should be involved, and estimation should consider all these areas.

Furthermore, the choice to only include the development team in estimation exercises can lower morale for other core functional teams who also play a crucial role in the project. Therefore, implementing a fun, interactive, and productive agile estimation approach and technique is a great way for remote or distributed teams to all get involved.


Agile Estimation Just Got Easier—and Better

The process of agile estimation doesn’t have to be difficult or overly complex. By having the right tools and techniques in your toolbox, estimation can be a fun and collaborative activity for remote and distributed teams.

We recently improved and released a new feature in our Agile Poker for Jira functionality that not only provides better estimating accuracy but is also a great solution for remote or distributed teams. In “Relative Mode” team members can join a Relative session, view and comment on Jira issues, and “vote” by moving cards around a collaborative board.


If you want to try out Agile Poker for Jira Cloud, then visit the Atlassian Marketplace today. You can also see how it works in action by checking out our fully functional demo option.