Alternative To Planning Poker Estimation (Best Techniques)
Planning Poker became the de facto standard for agile teams when it comes to estimations.
The reason is clear: its gamified nature makes it fun, and it stimulates discussion within the group to get a better understanding of the user story.
But isn't there always room for improvement?
To improve something, it's good to explore what else is out there. Maybe there are alternatives.
Maybe they are useful for us, maybe not.
Let's say your group grows quickly and there are new members who are unfamiliar with the initiative you're building. Their estimates will likely differ significantly from those of your experienced members.
There are other agile estimation techniques that could help in this situation.
Also, when it comes to a huge unestimated set of stories, Planning Poker requires discussions that take time. Sometimes, a lot of stories can be grouped together and quickly estimated.
Let's see which agile estimation methods exist out there.
Planning Poker
The classic one.
Team members discuss a story.
Then everyone votes for it at the same time.
If the estimation reaches a consensus, you proceed with the next one.
Otherwise, further discussion is needed.
In my view, this methodology is an incredible tool to encourage discussion and ensure that everyone has the same understanding of a user story.
It often happens that people work in different modules or parts of a solution and are not fully aware of the complexity outside their daily work.
The discussion when the estimate does not reach a consensus helps to bring these different perspectives together.
- Ensures a better exchange of knowledge
- Most precise due to consensus after multiple rounds
- Can be estimated in story points or time, making it trackable
- Takes long for one item
- Takes even longer the bigger the group
- Timebox one task.
- Best fit for small groups.
Affinity Estimation
Affinity Estimation focuses entirely on the relative comparison of stories.
This method is an excellent choice when an initiative starts and there are many stories that need to be estimated.
Additionally, it can highlight risky stories which probably should be analyzed in detail or tackled first.
- One member picks a story, reads it, and places it on the wall
- Another member takes another story and places it to the left if it is less complex or to the right if it is more complex.
- The third member can now decide to place the third item to the left, right, or between the first two.
- The person who places the task should explain why the user story is more complex than the one on the left and less complex than the one on the right.
- When all elements are placed, other members can shift already placed elements to other locations but need to explain why.
This ensures consensus is still reached.
As you see, the focus here is on relative sizes. Stories are compared to other stories.
Basically, this methodology is a sorting algorithm :)
- Visualizes complexity of stories and tasks relative to each other
- Fast to estimate as no detailed discussion of each story is needed
- Independent of group size and size of the stories
- Good for new initiatives with a huge set of stories
- No precise time/story point estimation, making it less trackable
- Members cannot provide direct feedback on a vote they disagree with; they need to wait until all cards are placed
- Create a column named “Too Huge”; these stories are out of scale and should be split
- If a story is shifted too many times, there is probably no consensus on it; use another methodology for this story
Bucket System Estimation
Another alternative to scrum poker is the Bucket System.
It's a great choice when your members specialize in specific aspects like UI/UX, business logic, database, and testing.
It forces the group to establish such categories and vote for each category on each story.
This sounds time-consuming but remember that only a few members estimate each aspect while others focus on different areas. This can be done in parallel.
Let's take a detailed look:
Define your categories and use a Fibonacci scale, as an example we define:
- 1 Page: 3
- 2-3 Pages: 5
- 3-5 Pages: 13
- More than 5 Pages: 21
- 1 Lambda Function or Business Rule: 3
- 2-3 Functions: 5
- 3-5 Functions: 13
- More than 5 Functions: 21
- 1 Simple Table: 3
- 1 Table with relationships: 5
- 2-3 Tables with complex relationships: 13
- More than 5 Tables or Tables with complex indices/relationships: 21
- S = 0 - 5
- M = 5 - 13
- L = 13 - 21
- XL = > 21
- Define your categories as shown above
- Each “expert” provides an estimation for their area like UI, business logic, or data storage.
- The numbers are summed and the story is placed into the corresponding bucket.
As you can see, the final result is not as fine-grained as in Planning Poker.
On the other hand, each aspect of a story is estimated in more detail. This provides a good balance: you still have KPIs to track and measure to visualize velocity, but during the scrum meeting, you can just focus on bucket sizes to quickly select some user stories for the new sprint.
- Estimates a story from different aspects
- Probably more detailed than other techniques
- Allows tracking of the velocity of different layers (UI/BL/DB)
- Estimation takes really long when all members are full-stack (experts in all layers)
- Sometimes members don't understand why some stories take much longer in other layers
Use this alternative to scrum poker only when you have dedicated members for specific product layers like DB, DevOps, frontend, etc.
Dot Voting
Dot Voting isn't an estimation method per se, as it can also be used to identify importance or issues.
- Each member gets a specific number of dots (votes).
My recommendation: if there are five stories assign each member five dots. - Place all stories on the board and explain if needed.
- Each member can now place their votes (dots) on the stories.
- A member can place multiple votes on one story if they wish.
- The task with the most votes is considered the most complex, and the one with the least votes is the least complex.
This is probably the fastest way to estimate.
It is the best approach to identify critical/complex product backlog items that probably need to be split.
Unfortunately, there is no real scale in this system, which means you cannot map votes/dots to story points. This makes it impossible to measure velocity and define a maximum for a sprint.
- Fastest estimation technique
- Best way to visualize relative complexity differences on a board
- Cannot compare with stories from other estimation sessions due to different amounts of votes/members used
- Not possible to track velocity
- I recommend using this practice to identify risks in a project, not complexity.
- It is also a great method when an initiative starts to identify a reference story for Planning Poker.
Conclusion
Choosing the right agile estimation technique is crucial for your team's efficiency and accuracy.
While Planning Poker remains popular, alternatives like Affinity Estimation, the Bucket System, and Dot Voting can address different needs and scenarios.
Each methodology offers unique benefits and challenges, so consider what works best for your team dynamics and project scope.
Remember, the goal is to facilitate meaningful discussions and reach a consensus, ensuring a smooth and productive scrum meeting guided by your scrum master.
