Dot Voting: Prioritization, Not Estimation

Dot voting isn't an estimation technique at all - it's a prioritization tool that teams reach for when they actually mean estimation, and confusing the two produces a backlog that's ordered but not sized. This page covers how dot voting actually works, why it belongs in a different conversation than "how big is this," and where it fits alongside real estimation. For the full technique family, see the complete agile estimation guide.

How dot voting works

Each participant gets a fixed number of "dots" - physical sticky-note dots in person, or clicks in a digital tool - to distribute across a list of options however they choose. All of one participant's dots on a single favorite, or spread across several: both are valid. Once everyone's voted, the options with the most dots are the group's priority, full stop. There's no discussion built into the mechanism the way there is in Scrum Poker - dot voting is fast specifically because it skips per-item conversation.

A typical setup: five options, each participant gets three dots. Someone might put all three on one option they feel strongly about; someone else spreads one dot across three different options they'd all be happy to see prioritized.

What question it actually answers

Dot voting answers "what matters most to this group, right now" - not "how much effort will this take." Those are genuinely different questions, and the entire failure mode of misusing dot voting is treating a popularity signal as a sizing signal. A feature can win every dot in the room and still turn out to be the most expensive item on the list; dot voting has told you nothing about that.

This is the single most common mistake teams make with the technique: reaching for dot voting because a backlog "needs to be estimated," when what's actually needed is a decision about what to build first. The two questions deserve two separate exercises, ideally in that order - prioritize first, then estimate only the items that survived prioritization.

Where dot voting genuinely fits

Deciding what to build among several viable options. A team with ten candidate features for next quarter and capacity for three uses dot voting to surface genuine group preference fast, without a long debate about each one individually.

Pairing with story mapping. Map the user journey first to see which stories are core to the experience versus optional, then dot-vote within a priority tier to break ties among options that are roughly equally important. Estimation with Scrum Poker happens afterward, only on the stories that survived prioritization - dot voting narrows the list, it doesn't size what's left. More on the mapping side: story maps for prioritization.

Retrospective topic selection. Outside backlog work entirely, dot voting is a fast way for a team to pick which of several retro discussion topics is worth the limited time in the room - a genuinely different use case, but the same underlying mechanism.

A worked example

A team has twelve candidate ideas for a quarterly roadmap review and thirty minutes to narrow them down. Each of eight participants gets four dots. Dots land on the wall next to sticky notes for each idea; people vote simultaneously to avoid the same anchoring problem numeric estimation faces (a couple of early, visible dots can influence where later dots land, so simultaneous placement matters here too).

Fifteen minutes in, three ideas have absorbed most of the thirty-two dots, four have a scattering, and five have none. The team commits to the top three for deeper scoping and shelves the rest - a genuine, fast, group-driven prioritization decision. Notably, nobody has any idea yet how big those three ideas actually are; that's the next conversation, run separately, likely with t-shirt sizing given how early-stage the ideas still are.

Dot voting vs. estimation techniques

The common mistake, and the fix

Using dot voting where the team actually needed an estimate produces a backlog that's confidently ordered and completely unsized - which surfaces as a surprise a sprint or two later, when "the thing everyone wanted most" turns out to also be the biggest item nobody scoped. The fix is procedural, not technical: treat prioritization and estimation as two separate exercises with two separate questions, run dot voting (or any prioritization method) first, and only estimate the items that survive it.

Estimate what dot voting prioritized

Once dot voting has narrowed the list, size what's left with a real estimation technique. Create a free room and run Scrum Poker on the stories that made the cut - private votes, one reveal, the conversation dot voting deliberately skips.