Should QA, Designers, and Developers All Estimate?

Start with the useful distinction

Cross-functional estimation can be very useful when different roles genuinely see different risks, dependencies, or definition-of-done implications in the same work.

But that does not mean every team should force every role to vote on every item in exactly the same way. The better question is whether the extra perspective improves the estimate or just makes the session heavier.

Why broader participation can help

QA, designers, and developers often notice different things. A developer may see technical complexity. QA may see test surface and failure paths. Design may see states, edge cases, or interaction detail the rest of the room glossed over.

That difference in perspective is often exactly what makes the estimate more honest.

• Developers surface implementation complexity.
• QA surfaces validation, edge cases, and test effort.
• Design surfaces interaction detail and experience states.

Why broader participation can also go wrong

More voices do not automatically create a better estimate. If the team has not clarified what the vote is meant to represent, the session can become slower without becoming more insightful.

The problem is usually not inclusion itself. It is unclear estimation purpose.

What the team should align on first

Before deciding who votes, the team should be clear about what the estimate is trying to capture. Is it implementation effort, end-to-end delivery complexity, uncertainty, or the overall size of getting the story truly done?

Different answers to that question naturally change who should be part of the vote.

When it usually makes sense for everyone to estimate

Broader participation is often useful when the story cuts across design, implementation, and validation in meaningful ways, and when the team wants the estimate to reflect the full delivery reality rather than just coding effort.

In those cases, the spread between roles can expose exactly the hidden assumptions the team needs to discuss before planning.

When narrower voting may be cleaner

For some teams, it works better to let a broader group shape the discussion while keeping the actual vote closer to the people doing the implementation-heavy part of the work.

That can make sense when the estimate is specifically meant to reflect delivery effort as the developers see it, while still incorporating context from QA and design before the vote happens.

What usually makes the debate feel bad

This question tends to become frustrating when the team treats different votes as role conflict instead of useful input, or when the story is still so vague that role-based disagreement is really just unreadiness in disguise.

• The team has not agreed what the estimate represents.
• Stories are too unclear for any role to estimate honestly.
• People defend role territory instead of surfacing assumptions.
• The session gets heavier without producing clearer reasoning.

Where to go next

If your team wants to settle this debate in practice instead of theory, the poker tool and the estimator are the best next steps.

Use poker to see how different roles actually view the work, and use the estimator when the team needs a clearer shared framework for why those perspectives landed in different places.

TL;DR

• QA, design, and development can each reveal different estimation risks.
• Broader participation helps when the estimate should reflect full delivery reality.
• It becomes messy when the team has not agreed what the estimate represents.
• Cross-functional estimation helps most when the goal is better reasoning, not just collecting more votes.