Why role-specific estimates beat one number

Estimation meetings drag, and the number still feels arbitrary. Six people flip their cards, someone reads out an average, the team nods, and the story goes into the sprint with a 5 on it. Two weeks later it is still open, and everybody remembers that the QA engineer had voted 13.

The problem is rarely the people or the scale. It is the step where a room full of different opinions gets collapsed into one number. This post is about why that step loses the most useful information in the meeting, and what to do instead.

One average, three different stories

Take a single user story: "Let customers download their invoices as PDF." The team votes on a Fibonacci scale and the cards come up like this:

• Developers: 3 and 3
• QA: 8 and 8
• DevOps: 5

The plain average of those five votes is 5.4, which rounds to 5. On paper that is a calm, mid-sized story. In reality the room just told you three different things:

• Developers see a small change. There is a PDF library already in the codebase and the invoice data is one query away.
• QA sees a large one. Every invoice template, every currency, every locale with its own date and number format has to be checked, and PDFs are painful to assert on automatically.
• DevOps sees something in between. Rendering PDFs on the server needs fonts in the container image and a bit more memory, and someone has to watch for timeouts on large invoices.

None of those people is wrong. They are estimating different parts of the same work. A single average of 5 does not describe any of them. It is too high for the developers, far too low for QA, and it hides the one conversation the team actually needed to have: how do we test this without it eating the sprint?

What per-role averages show

Planning poker with role groups keeps the votes apart by role. Instead of one number, the reveal shows each group's own average side by side:

• Dev: about 3
• QA: about 8
• DevOps: about 5

Now the spread is the headline, not a footnote. Two things happen almost immediately.

First, the discussion starts in the right place. Nobody needs to ask "who voted high?" because the QA column is sitting there at 8. The question becomes concrete: what makes testing this story so much bigger than building it?

Second, the outcome of that discussion is usually a better story, not just a better number. Maybe the team agrees to test two representative templates by hand and automate one. Maybe the story gets split so the locale work becomes its own ticket. Either way the decision is visible and owned, not buried in a rounded mean.

Reading the result

Seeing the role averages side by side also makes it easy to judge how much to trust the number. In EstimateTask every reveal shows:

• The distribution by team, so you can see every role's spread, not only its average.
• A final estimate, taken as the median across the role groups, so one outlying group cannot drag the result on its own.
• The overall average, snapped to the nearest value on your scale.
• A confidence level of high, medium or low, based on how far apart the role averages are. When they are far apart, the reveal says so: high variance.

A low-confidence reveal is not a failure. It is the meeting doing its job: it found the story where the team's mental models disagree, before the sprint did. The usual move is to talk, then revote. Every round is kept, so you can see how the numbers moved after the conversation.

When one number is enough

Some stories really are one piece of work that everyone sees the same way, like a copy change or a small bug fix. For those, a task can be set to flatten groups, which pools every vote into a single average instead of keeping the roles apart. It is a per-task choice, so a team can flatten a quick fix and keep roles separate on a feature with real testing and infrastructure work.

Hidden votes still matter

Per-role averages only work if the votes are honest, and votes are only honest if nobody sees them early. Cards stay face down until the reveal, the "trending towards" hint appears only after the reveal, and a guest or a junior teammate votes exactly like everyone else. The point of the reveal is that the loudest person in the room cannot anchor the number.

How to start

If you want to try this with your own team:

1. Create role groups that match how your team actually works. Developer, QA and DevOps is the common starting point. Add Design or Data if those people regularly carry part of the work.
2. Put every member in their group. Guests pick their group when they join from the share link, so a contractor's vote lands in the right column.
3. Run a normal planning poker round. The only difference is what you look at after the reveal: the spread between roles first, the final number second.
4. Talk about the widest gap before you revote. That one conversation is where most of the value of estimation actually comes from.

You can try it on the Free plan with one project, up to five members and unlimited guests. See the features for the full picture, or start free and run your next refinement session with the roles kept apart.