Product managers, project managers, and software developers 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 an estimation rather than a hard, concrete number.
Additionally, determining when and how to estimate in the first place is also a challenge, and yet, answering these questions is essential for launching, delivering, and deploying a successful project.
The good news is that there are several estimation techniques in agile project management. One common method is Planning Poker. But like any technique, there are advantages and disadvantages to using it.
This article will explain Planning Poker, how it works, and the advantages and disadvantages of using it. We will also discuss Relative Mode and why teams should consider it 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
Most 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, 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 unrelated to the particular project. This includes answering emails, meetings, or other task management activities 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’ experiences. The session should facilitate discussion to ensure 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 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 their estimate. Sometimes team members will reach a consensus easily; other times, they will discuss and debate to reach an agreement. Some tasks or stories are easier to estimate than others.
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.
Advantages and disadvantages
There are advantages and disadvantages to Planning Poker. One clear advantage is that each team member can “voice” their estimates, encouraging 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 first, never mind come up with accurate estimates.
Furthermore, it isn’t wholly relative, and it can make 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 actual idea of relative estimation is to compare items against each other. That’s why Planning Poker is very often recommended for teams with more considerable story points experience.
Relative Mode: An alternative estimation method
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 more significant experience in estimating that want to speed up the estimation process. If you prefer a visual representation and interaction, this method is for your team.
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
This makes it an easier and 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” 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 with 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 quickly move the tasks or issues into a column for estimation, collect estimates from the team, save them, and move on to the next—and all in one view.
3. It is more productive and faster
Relative Mode effectively produces and drives fairly accurate estimates 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. It 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.
4. It is more collaborative
Relative Mode is more straightforward by saving time and effort from setting up and explaining a “game” of Planning Poker.
The session moderator selects an issue or task to estimate, each participant or team member submits their response, and the team reaches a consensus. If they do not reach an agreement, they can discuss and deliberate accordingly and re-estimate them.
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 agile estimation process doesn’t have to be complicated or overly complex. By having the right tools and techniques in your toolbox, an estimation can be a fun and collaborative activity for remote and distributed teams.
Agile Poker for Jira provides better estimating accuracy and 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.
You can try Agile Poker for Jira here.
Last updated: 2023-07-31
Oleksii Kovalenko
See all content by Oleksii Kovalenko
