Planning Poker: An Agile Estimating and Planning Technique

Planning poker can be a useful estimation technique for any team in any organization. But the approach works particularly well for smaller businesses and smaller teams. The more people participate in a planning poker session, the longer it will take to reach a full consensus on each item. Planning poker is applicable to any process that requires an estimation of effort involved in upcoming work, not just software development. You can use it to estimate the work required to redecorate your home, landscape your yard, organize an office move — the list of potential applications for planning poker is endless. For Agile teams, planning poker is a great addition to the product planning and development process.

This is your baseline, every estimate is a comparison to this story. Lay out what tasks will be included in this story so that everyone has an idea of what they’re going to be voting on. Roman Gun, Vice President, Product at Zeta Global, discusses his approach to formulating processes around the team’s goals and capabilities. This indicates that some parties involved consider the work to be more complex than others around the table do. The next step would be to determine what’s causing this difference of opinion. Planning Poker also increases team morale by giving everyone an equal voice.

As a result, people feel they are being listened to, making them care more. Also, this encourages diverse opinions, which can help consider factors that a more homogenous set of views may overlook. It’s fun, exciting, possibly rewarding, and there are so many different types to choose from. You can play 7-Card Stud, Texas Hold’em, 5-Card Draw, and Omaha. Or you can leverage an Agile technique known as Planning Poker®. The group will also try to learn more about the story and ask questions to understand it better.

How Does Planning Poker Work?

When everyone is ready, all participants reveal their cards at the same time. Planning poker is based on a list of features to be delivered, several copies of a deck of cards, and optionally, an egg timer that can be used to limit time spent in discussion of each item. Agile Release planning leverages this poker point system to determine when product releases can occur and how many sprints are required to complete the project. For this article I am going to focus in on how points are assigned to project deliverables using a process call Planning Poker. Planning Poker is a Agile Project Management work estimation process.

Agile projects have the same need to determine a project end date, but the estimate system works very differently. Planning Poker leverages the knowledge of the team to estimate work effort. This aligns with the idea that the team is responsible for the work. Planning Poker uses a relative point system and does not attempt to measure effort in work time or duration, just a level of difficulty relative to other items in the backlog. The first step of planning poker is to pass out your planning poker cards.

Step 1: Hand out the cards to participants

Asana helps you plan and organize your Agile projects in a tool that’s flexible and collaborative. Whether your team works in a Kanban board or a more linear timeline, Asana has the features to help your Agile team build quickly. Planning poker is based on a technique known as Wideband Delphi.

• Simply log in to the tool and preload a set of items to be estimated.
• After everyone has had their say and gotten any questions answered, each person will secretly choose a card from the deck to represent their estimate of story points.
• Asana helps you plan and organize your Agile projects in a tool that’s flexible and collaborative.
• Strictly speaking this process continues until you reach full concensus, but I typically go with the clear majority.
• In 2002, James Grenning created planning poker as an alternative to the popular project estimation processes of the day because he didn’t think they solved these problems particularly well.
• This is important on an agile project because the user stories being estimated are often intentionally vague.

Next, the product owner (or possibly a product manager) will read each story out loud to the group. When estimates are revealed, if the estimates are the same for all team members, that is the number to add to the User Story. Maybe the team member who scored the task a 13 thinks we’re building the work from scratch and therefore it carries a lot of risk and uncertainty. Maybe the team member who chose 2 knows that they had already built this function two years ago and it was just a matter of dusting it off and redeploying it. These are both things that may not have come up during the discussion. When the first piece of work is described to the group, the members have an opportunity to ask questions and clarify the requirements.

In a typical waterfall project all the work tasks have time estimates (usually in days) and deadlines. By applying task dependencies and resource levelling a project end date and cost are determined. This backlog keeps on increasing after the user adds some requirements. In that case, teams have to work parallely in calculating the estimation once per iteration. Be sure to check out Mountain Goat’s upcoming Training and Events, Books and Articles on Scrum, agile estimating & planning and working with user stories.

Each person should lay down their estimation face down from their deck. Once everyone has done this, the entire team flips their cards face up in unison. You then move from one person to the next as the reasoning behind each estimation https://www.globalcloudteam.com/ is shared. Unlike many agile development exercises, planning poker follows a pretty standardized series of steps. You’re unlikely to see a lot of variation within the exercise, particularly because it’s so simple by design.

They compare the complexity of the new assignment against past challenges and rank the difficulty as well as the time required. Or is it really huge like that one piece of work we finished last month? Doing relative estimates will not only reduce the amount of time spent on estimating work, it will also heavily increase the accuracy of the estimates. Result – The estimates based on group discussions were more accurate than the individual estimates. LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

It was also noted that for the same tasks, planning poker estimates were more accurate than individual ones. The reason to use planning poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants’ sizing. Planning poker should force people to think independently and propose their numbers simultaneously.

The main benefit of planning poker is that your team estimates are more accurate. Having an accurate estimate is an important part of the sprint planning process, because it gives both your team and stakeholders a realistic timeline for when a task will be completed. Now it’s time for each person to come up with their estimation for how long this story will take to be completed.

Planning Poker also helps team members anticipate how many people they will need to work on a given task. This way, you will avoid the extremes of not having enough people or assigning too many people, resulting in a duplication of effort. Requiring a consensus among the team, rather than having one person dictate estimates, can increase morale by giving everyone on the cross-functional team a vote. The higher a participant’s card is, the more difficult that participant estimates the story will be to complete.

To help gauge the number of story points for the relevant tasks, teams use planning poker cards, which are similar to poker cards. Planning Poker is one of the commonly used agile estimation techniques that has helped several teams to estimate the required time and effort to complete a project. The name comes from the game “poker”, which you might have heard.

This is an opportunity for the various stakeholders in this story to offer up their input. For example, if this will require debugging, have the people who will be completing this task provide their insight. Story pointing allows the team to focus on the complexity and time involved in delivering a piece of work. The team compares the new work against work they’ve already done.