Mob Estimation: When the Whole Team Votes at Once

Standard planning poker has a structure: stories are read, each developer votes privately, then votes are revealed. Mob estimation keeps that structure but runs it with everyone physically (or virtually) together, all voting and discussing as one group.

How it differs from standard planning poker

In standard sessions, developers might vote from their desks at different times, then join a call to discuss. In mob estimation, the whole team is co-present from the start: everyone hears the story at the same time, thinks at the same time, and reveals at the same time.

This eliminates one common failure mode: asynchronous discussion that creates anchoring before the vote.

When mob estimation produces better results

High ambiguity stories. When nobody is sure how to approach something, having everyone in the room simultaneously surfaces the right questions faster. The developer who worked on the related module, the QA person who knows the edge cases, and the designer who understands the user need can all contribute in real time.

New teams. Teams that haven't developed a shared context yet benefit from the explicit knowledge transfer that happens when everyone discusses every story together.

The cost

Mob estimation is time-intensive. If ten developers are in a room for three hours, that's 30 person-hours for one planning session. For a mature team with a well-refined backlog, this is waste. For a new team or a complex product area, it's investment.

A hybrid approach

Use mob estimation selectively: for the stories with the widest spread after the first round, pull everyone in for a focused group discussion. Run the straightforward stories asynchronously or in smaller sub-groups.

Mob estimation trades time for shared understanding. Use it when the understanding gap is large enough that the trade is worth it.