Top managers frequently put a lot of pressure on product development teams to ensure that estimates are as accurate as possible. However, it is important to remember that an estimate is just that: an estimate, not a hard, concrete number.
It is also difficult to figure out when and how to estimate in the first place. Nevertheless, answering these questions is critical for a successful project launch, delivery, and deployment.
The good news is that there are various estimation approaches to choose from in agile project management. Planning Poker is a popular strategy. However, like with any approach, there are benefits and drawbacks to employing it, as you will see in this article.
Agile teams can use planning poker, also known as Scrum poker, to estimate the time and effort required to finish each initiative on their product backlog. Because participants utilize tangible cards, strategists call this gamified strategy planning poker. The number of story points for each backlog story or task up for discussion is estimated using these cards, which resemble playing cards.
The purpose of Planning Poker is to support software companies in more correctly estimating development timelines, gaining consensus among cross-functional team members, and tactically planning the team's project.
Planning poker’s origins can be traced back to the RAND Corporation's Wideband Delphi estimate approach, which strategists created in the mid-twentieth century.
Then, James Grenning, a software entrepreneur, improved the concept in 2002, renaming it Planning Poker and customizing it for agile development teams.
Finally, Mike Cohn of Mountain Goat Software popularized planning poker with his book Agile Estimating and Planning in 2005.
Truly, Planning Poker has come a long way since its inception.
Planning poker brings stakeholders, whether product owners, developers, UX designers, QA testers, and product managers from several departments, to agree on the projected work required for several backlog activities.
The Planning Poker process comprises five major steps:
Each participant is given an identical deck of cards with a different number on each one. One typical sequence is 1, 2, 4, 8, 16, 32, 64, based on doubling each number. Mike Cohn of Mountain Goat Software, who popularized planning poker for agile development, recommends the following sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
Because the goal is for all participants to obtain a consensus number for each story, the decks are limited, with substantial number jumps.
The product owner, or potentially a product manager, will read each story aloud to the group.
The group will discuss the story now that everyone has heard it. Participants will outline how they plan to handle the project, including how many people they expect to be engaged, the skill sets that will be necessary, and any potential roadblocks.
After everyone has spoken, and any questions answered, each person will select a card from the deck to symbolize their estimate of story points. When everyone is ready, everyone reveals their cards simultaneously.
If all of the participants show the same card, the consensus is that number. The group is now ready to move on to the next story. If the cards are different, the group continues to discuss the story. Those with greater or lower estimates than the rest of the group will explain why they receive that estimate. Then, they would attempt to persuade their coworkers to agree with them.
Planning poker is an estimation strategy that any team may use in any organization. However, the strategy works especially well for small organizations and teams. Larger organizations typically have larger teams; thus, the more individuals in a planning poker game, the longer it will take to get a full agreement on each item.
After an initial product backlog gets created, most teams will hold a Planning Poker session. This session, which may last several days, provides preliminary estimates for scoping and sizing the project.
Because product backlog items, typically in user stories, will be added during the project. Most teams will find that conducting subsequent agile estimating and planning sessions once per iteration is beneficial. Because the entire team is present at that moment, this is usually done a few days before the conclusion of the iteration and shortly after a daily standup.
Although each project may have compelling reasons for using Planning Poker, you can generally note the following benefits.
First and foremost, Planning Poker is simple, fast, and precise. When the entire team, with different functions, is given the authority to estimate, you can obtain incredible accuracy quickly. When it comes to meeting project objectives, accuracy in estimation saves a lot of time and surprises. Furthermore, when the participants' assessments get offered, they must explain why certain estimates are high and others are low. This discussion may lead to questions regarding the requirement and how it got implemented, which can be a good feedback loop for detecting holes.
Second, Planning Poker promotes teamwork. During these sessions, both introverts and reticent people receive equal time to speak, which helps them open up. Quiet people are more likely to have better ideas, and when they give an "outlier" estimate, the entire team pays attention to them. Furthermore, this planning technique encourages members to produce and submit their assessments rather than taking others’ views at face value. New members of the team, in particular, can quickly grasp various aspects of the projects during these sessions.
Third, Poker Planning allows you to have fun while remaining productive. Everyone is kept occupied and busy. The beauty of this type of estimation is that each individual must justify why their estimates are correct. Participants must evaluate all aspects of the implementation/testing activities to defend their assessment. People are also more inclined to participate and produce the greatest results when work and play are combined.
Finally, because the entire team debated and agreed on a story estimate, they are now responsible for finishing the work on time. Because the group gets involved from the beginning, this strategy instills a sense of ownership in everyone.
As with any estimation endeavor, Planning Poker is not without its drawbacks and disadvantages.
To begin with, reaching a consensus can offer the team a false sense of assurance. The team could still be lacking crucial bits of information, and their estimate could be incorrect.
The second drawback in these practical meetings is that one or two practitioners often dominate the discussion, with other practitioners just echoing or remaining silent. In a group, a dominant individual might exert undue influence over the other members. If you are not careful, it can lead to estimates based on willpower rather than consensus.
Third, research shows that a group estimate is more positive than a projection made by individual members of the group. As a result, the discussion phase of a planning poker meeting might lead to a team convincing itself that it can accomplish more in less time than it can.
Finally, the so-called "anchoring" effect, which is a prevalent difficulty in the group discussion-based estimation process, is another looming source of disadvantage. Even if the estimates or expectations are unrealistic, “anchoring” can be regarded as an impact on subsequent calculations once someone puts up an estimate or expectation on the size of a user narrative in a group discussion-based estimate process. For example, an estimator may attempt to provide a similar result to another estimator's estimate.
Apart from the challenges above, another typical question that creates a disadvantage begs to be answered: whether the efforts of other roles must also get included when providing individual estimate results. The answer is that when making individual estimates, each practitioner can evaluate the appropriate action in their particular function. Still, the final estimate result will consider the effort put in by the entire development group.
Indeed, in agile methodology, the software estimate was designed to estimate the relevant effort involved in the entire development phase of each user story, starting with the development of a user story, testing a user story, and ending with the completion of a user story. As a result, the final estimate result must include the effort put in by all development team members.
The agile estimation process does not need to be difficult or time-consuming. On the contrary, if you have the right tools and tactics in your toolkit, the effort estimation process may be a fun and collaborative exercise for remote and distributed teams.
In this respect, Async Poker is a good option for your next Planning Poker project. Async Poker is a tool for estimating product backlog work in Jira in an asynchronous manner for collocated, distributed, or remote Agile teams. With Async Poker, you may be confident that your estimates will be not only speedy but also correct.
