21 July 2022
The estimation process is a common headache that agile teams face. At first glance, it is extremely simple: you have to predict the amount of effort to complete a particular pool of tasks. But estimation is a two-way street—it can benefit you while breaking a large user story into short and easy tasks, but one wrong step can mess things up.
In most cases, management encourages squad members to provide more accurate predictions—but it is not as easy as it looks. Agile teams have two goals: to select the perfect estimation approach and choose the right time frame. And agile planning poker is a great option for advanced project planning.
The Origin of Planning Poker
Planning poker (or Scrum poker) was defined by James Grenning, founder of Wingman Software, in 2002. It happened when he was looking for another option to the Wideband Delphi estimation method, which was popular at the time but had too many limitations (e.g., enormous time commitment). Grenning believed that the planning poker estimation technique is perfect for resource optimisation and making the whole process more efficient. Later, Mike Cohn popularised this approach in the book Agile Estimating and Planning.
What is Planning Poker?
Planning poker is a technique which involves the whole team to estimate the volume of sprint tasks using a unique deck of cards. This approach helps in-house and dedicated development squads to distribute the effort among all game participants.
When implementing the planning poker method, squads review a selection of tasks to complete during the further user story. Then, each participant solely estimates the amount of effort each feature will require. Here, employees use a customised card deck with a specific amount of story points* on each item indicated.
*Story points reflect the amount of work the agile development team can complete in an average sprint.
Each participant has to pick the card secretly and then show it to other participants simultaneously. After that, all team members discuss how many story points each feature requires to reach a consensus on the overall effort to complete the user story.
When Should You Organise the Planning Poker?
In most cases, you need to hold a planning poker meeting shortly after creating an initial set of tasks. Thus, this session helps to determine the first estimation figures that can be used while sizing the entire development process.
Because the agile team will continue to add new user stories throughout the project, they have to conduct planning poker sessions once per sprint. It is better to organise such a meeting a few days before the iteration ends and right after the Daily Scrum as the whole squad is together at that time. However, many agile teams conduct a PBR (product backlog refinement) where they discuss the user story and its estimation.
Who Has to Participate in Planning Poker Meetings?
If you expect to benefit from planning poker sessions, you have to involve the right people. Here are the critical participants:
- Scrum team employees provide a list of new features from the product backlog. The squad members also participate in story points discussion.
- Scrum Master acts as the host of planning poker meetings and all standard agile meetings.
- The product owner describes the idea of each user story and answers all the questions from the team.
You can also involve employees from other teams if this helps to understand the client’s needs better and understand how to implement the feature in the best way.
The planning poker technique is used to estimate story points, a metric that determines the effort to complete the user story. Learn more about the story points notion here.
How Does Planning Poker Work?
This event brings together the entire development team to find common ground on estimating efforts required for executing different tasks. However, the positive session outcome depends on the correct organisation.
Prepare the Cards
Each participant gets an identical customised deck of cards with planning poker numbers 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 story points (modified Fibonacci sequence). Mike Cohn, the planning poker populariser, recommends this sequence because it considers that larger tasks are usually more complex and, thus, difficult to estimate.
Moreover, such an amount of number jumps makes estimating process more efficient since all agile squad members can reach a consensus for each task.
Check Out the User Story
The product owner provides all participants with the details of the user story. Ideally, this employee has to read it out loud to others.
Start a Discussion
Once everyone has heard the user story, the development team discusses it. Each participant shares the workflow vision (number of people involved, tech stack, possible risks) and asks questions about the story to the product owner.
Estimate and Share
After everyone has shared their opinion and received answers to questions, all participants anonymously choose a card with the number of the story points the task will take to complete. After that, the team simultaneously put scrum poker cards on the table.
The higher the number indicated on the card, the more effort should be made to complete the user story.
Reach a consensus
Ideally, everyone should have the same score, but it doesn’t always work out the first time. So the discussion starts over, and those with higher estimates have to explain their choice and attempt to convince the rest participants to reconsider their positions.
If you understand that it will be difficult for them to achieve an unambiguous and unanimous opinion, you can agree with the team on choosing the highest score. But remember: you need to do this before you start.
Once the discussion ends, each participant will review their cards and choose a new estimate or keep the previous one. All the team will again reveal their planning poker cards simultaneously.
The Planning Poker benefits
According to the article published in the Journal of Systems and Software in 2008, planning poker estimates are higher than individual estimations, but they provide more accurate predictions.
A planning poker session has some other critical advantages:
- You can evaluate tasks close to each other. Often, agile development teams have difficulty estimating the effort required to complete a user story (especially when doing it for the first time). Planning poker familiarises participants with such an evaluation approach. After playing the first round, the entire squad gets a template for further meetings.
- Everyone has an equal voice. This approach can encourage new employees to share their opinion and experience. Suppose your team has to add new features to the taxi app. You might give a smaller estimate to a specific backlog item (like 13 or 20 story points), but a new employee might set 40. Maybe they worked on similar projects earlier and know that such a feature takes more time to develop.
- You can detect gaps in project requirements and implementation. When the entire team reveals their estimates, they should defend them with arguments on why they chose this figure. Of course, it can raise questions about the project requirements and implementation, but it helps to identify the gaps and fill them.
Plus, planning poker makes the entire agile squad feel more enthusiastic and dedicated to a plan they helped create. Therefore, team members work harder to achieve the project goals.
Conclusion
Planning poker is an excellent approach to evaluating the squad’s effort for new feature development. The whole team can reach a consensus and provide more accurate predictions. You can conduct on-site meetings or play scrum planning poker online, which can be especially useful for remote teams. In any case, this approach acts as a valuable resource for prioritising items in the product backlog. At Rocketech, we implement advanced estimating techniques to plan the development process properly. Therefore, our dedicated teams can complete tasks more effectively and develop functional software. If you want to benefit from the effective partnership and grow your business, contact us now.