Poker Method In Agile

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.

• Poker Method In Agile Scrum
• Poker Method In Agile Methodology

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.

• Planning Poker is a highly efficient agile planning and estimating technique which has become exceptionally well-known over recent years. It is based on a procedure known as Wideband Delphi that was made by the RAND Corporation between 1940 and 1968, the exact year unknown.
• Planning Poker or Scrum Poker is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs.

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.

Teams starting out with story points use an exercise called planning poker. At Atlassian, planning poker is a common practice across the company. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate.

Fibonacci number for Story Point. When the development team conducts an estimation, it is recommended to abandon the traditional “human-day” assessment method, using the point of the story point, using the Fibonacci number (1, 2, 3, 5, 8, 13, 21) to estimate the story point (see Planning Poker article for detail). To prioritise the recommendations, we used a custom nine-point scale (0 = not important, 8 = extremely important) inspired by the planning poker agile method 27. These recommendations are highly.

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:

Poker Method In Agile Scrum

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.

A story point is a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms, a story point is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

Story point estimation, a kind of relative estimation, is typically performed at the Product Backlog Grooming Sessions and the Product Backlog is evaluated by the team who responsible for the actual development and testing work.

In order to make the Sprint Planning more efficient in practice, PO and the Team will make a rough estimation called product backlog grooming before the Sprint Planning and check for:

• If the Sprint Plan is readily to be conducted efficiently?
• Is there enough information to complete these matters?
• Is the user story split reasonably?

Best Scrum Software Every Project Needs

A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.

Fibonacci number for Story Point

Poker Method In Agile Methodology

When the development team conducts an estimation, it is recommended to abandon the traditional “human-day” assessment method, using the point of the story point, using the Fibonacci number (1, 2, 3, 5, 8, 13, 21…) to estimate the story point (see Planning Poker article for detail).

How to do Agile Estimation?

In order to do that each team would have to find a baseline story. It does not necessarily to be the smallest one, but the one that everyone within the team can resonate with. Once determined, sizing of all the user stories should be initiated by comparing them against the baseline.

When estimating new stories all you have to do is pick a story and say: “will this take longer than reference story x?” or “will it be less than reference y?” With enough reference stories there should be a suitable comparator to find a similar sized story and give it the same points or a bit more or a bit less based on a considered factor.

While estimating story points, we assign a point value to each story. Relative values are more important than the raw values. A story that is assigned 2 story points should be twice as much as a story that is assigned 1 story point. It should also be two-thirds of a story that is estimated 3 story points.

In addition, it is important to note that when the single story point of the assessment is greater than 21, the user story needs to be split again, and the single user story point is no more than 8 is the most rational state.