How it worksBlogFAQSupport
Do Async stands with our friends and family in Ukraine, and with all people of Ukraine.
Help Ukraine >

5 Alternatives of Planning Poker Estimation Technique

Estimation is an essential activity for agile teams to have a mutual understanding of the product backlog and become more committed to the work. Keep reading to learn about the 5 alternatives of Planning Poker estimation technique.
August 1 · 6 min read
Learn which alternative to planning poker you can use.

Planning Poker is one of the most widely used estimation techniques in agile projects. Its consensus-based estimation, driven by a fun and easy gamified approach helps teams accurately estimate their product backlogs. Although agile teams around the world are using Planning Poker, still there are teams that don't find themselves compatible with Planning Poker. It may be because the teams don't want to poker hundreds of stories, don't have enough time to do detailed discussion, or don't have enough information about user stories.

For those teams that are uncomfortable with Planning Poker, there are a few best alternatives to Planning Poker that they can try out and still do estimates of their product backlog. In this article, we are presenting the 5 best alternatives of the Planning Poker estimation technique with detailed steps on how to use those techniques. So, let's get started!

5 Alternatives of Planning Poker Estimation Technique

The main targets of estimation in agile are to encourage relative estimation, create mutual understanding, and become committed to the work. In this perspective, below are the 5 alternatives of Planning Poker that can help teams to achieve the estimation targets:

1. Async Poker

Async Poker or Asynchronous Planning Poker is the modified form of Planning Poker that addresses some key challenges teams face with Planning Poker and also facilitates remote members to actively participate in estimation sessions. Let's first take a look at what Planning Poker challenges are addressed by Async Poker.

Planning Poker requires all members to join the session and keep themselves involved in the estimation process until all the user stories are estimated. So, if one or two members don't come to the meeting on time, the whole estimation session gets delayed. Moreover, another issue with Planning Poker is that it requires an instant understanding of user stories and providing estimates right away. So, newbies or members that require some time to understand user stories might not be able to grab the concepts instantly and might fail to provide inaccurate estimates. These are the two key challenges that Async Poker addresses effectively.

In Async Poker, team members don't join the estimation session. They read and estimate user stories on their own and later participate in a brief session if the consensus is not reached. Below are the steps involved in the Async Poker estimation technique:

  1. The moderator (most likely scrum master) sends the stories to the members via email or other channels and also mentions the deadline by which they have to send their estimates.
  2. The members read and understand the stories at their own pace and finalize their estimates. Once all estimates are completed, they send the estimates back to the moderator.
  3. The moderator receives all members' estimates and sees if all members have given the same estimates or if there are some deviations in some stories. If there are some deviations, then the moderator calls a remote session where the members participate to quickly discuss those stories, re-estimate, and reach a consensus. However, if there are no deviations in the estimates, then the moderator finalizes the team's estimates of all the user stories and informs the members.

This way, Async Poker empowers members to have a better understanding of user stories and still reach consensus without disturbing the work schedule of members.

2. Bucket System

The Bucket System is another relative estimation technique that engages the whole team and can estimate a large product backlog in minutes. The "bucket" here implies the numbered sticky notes that are set horizontally on the table or wall in a sequential manner.

In the Bucket System estimation technique, the team members discuss the user stories, put them beneath the right buckets, and quickly reach the team's estimate. Below are the steps involved in the Bucket System estimation technique:

  1. The members join the meeting room. The meeting facilitator arranges sticky notes on the whiteboard or table in a sequential manner with numbering as 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, and 200. In addition, all the product backlog items that are to be estimated are written on small papers or cards to later place them under buckets.
  2. The meeting facilitator or any other team member picks one card, read it out, and then places it under the bucket labeled as "8". Now this story will be used as a reference to place other stories.
  3. The member picks another card and reads it out. The team then mutually decides the position of that card in the bucket in reference to bucket 8 and places the card in the agreed position.
  4. The member again picks the card, reads it, and then mutually places the card in the right bucket location.
  5. Now the remaining cards are divided equally among members.
  6. Each member read the card himself and then places it in the right bucket without discussing it with others.
  7. When all members have placed their cards in the buckets, the team quietly reviews the cards to make sure that they are positioned in the right bucket. If a member finds some issue in a card, then the team can quickly discuss around it and reach a consensus.
  8. Lastly, the team writes down the bucket number on every card.

This is how the Bucket System estimation works. It provides a quick way of estimating a large number of user stories and can even engage a large team in this process.

3. T-Shirt Sizing

As the name implies, T-Shirt Sizing is an estimation technique that uses t-shirt sizes, i.e., XS, S, M, L, XL, and XXL to estimate user stories. In this estimation technique, the team discusses a user story and then assigns one of the t-shirt sizes. The size estimation is made relative to others. For instance, if one story is given the size "M", then it means that story is at least twice or four times smaller than the story with the size "L". It mainly depends on how a team wants to handle relative sizing.

Once the team has assigned sizes to all stories, the team can then even set numeric values to those stories. Below are the steps involved in the T-Shirt Sizing estimation technique:

  1. The members join the meeting and are handed cards with XS, S, M, L, and XL labels.
  2. The product owner narrates the user story to the team. The team members listen and then clear their doubts.
  3. Once all doubts are cleared, every member pick's one card and they all show their cards simultaneously.
  4. If every member showed the same card, then it is considered the team's estimate. Else, the team quickly re-discuss the story, clear doubts, and re-estimate.
  5. The above steps continue until all stories are estimated.
  6. Lastly, the team can set numeric values to the estimates or even estimate the time needed to complete them.

Overall, the T-Shirt Sizing estimation technique is a lot similar to Planning Poker, just it distinguishes itself with its t-shirt size model.

4. Affinity Estimation

Known as the estimation technique for a large count of user stories, Affinity Estimation is used by mostly small teams to quickly and easily estimate user stories. In this technique, the user stories are estimated by comparing their sizes with others. The members first take a few cards (user stories), place them on the scale, and then gradually move and place all cards until they are estimated relative to each other.

Affinity Estimation serves best when the project is just starting and there is a large backlog that is still not estimated. Below are the steps involved in the Affinity Estimation technique:

  1. Take a scale and mark its one end as "Smallest" and its other end as "Largest".
  2. Let all members join the meeting. Afterward, the product owner gives them cards (user stories).
  3. Each member understands the story on his own and places it somewhere in the scale that he thinks suits the position. Similarly, every member understands and places all the cards one by one on the scale without discussing with others.
  4. Now members will do collaborative editing in which they will discuss the stories and rearrange the scale.
  5. After rearranging the scale, the team now has to assign story points to each story. For that, the scale is divided into sub-sections, i.e., XS, S, M, L, and XL, and then the stories are placed beneath those sub-sections.
  6. Lastly, the team now sets the story point to every user story, such as XS = 1, S = 2, M = 3, L = 5, and XL = 8.

That's it! This is how agile teams use Affinity Estimation to estimate a large number of user stories in minimal time.

5. Dot Voting

Dot Voting is another simple but effective agile estimation technique that is used when there are a small number of product backlog items to be estimated. The "dot" represents any sticker that the members will place on the user stories.

In the dot voting technique, the number of dots a story receives reflects its size, i.e., more dots mean a large size. Below are the steps involved in the dot voting estimation technique:

  1. Product owner places all the user stories on the wall or table.
  2. Every member gets a few dots (small round sticky notes).
  3. Every member is asked to place dots on stories they think are bigger in size than others. Members keep doing this until all their dots are utilized.
  4. The story with the highest number of dots is declared the biggest and the story with the lowest number of dots as the smallest.
  5. The product owner then arranges the stories from higher to lower order.

This way, a team can quickly and instantly estimate a small group of stories using the simple Dot Voting estimation technique.

Wrapping Up

Estimation is an essential activity for agile teams to have a mutual understanding of the product backlog, estimate the efforts, and become more committed to the work. The estimation techniques we have discussed above are the best alternatives to Planning Poker. They are used by different agile teams depending on their business models. So, if you are in search of a better alternative to Planning Poker, then discuss the above 5 techniques with your teammates and pick the one that suits your needs.

Copyright © 2022, Do Async. All Rights ReservedPrivacy policyTermsSecurity