Planning poker for QA: how to estimate testing effort

Ask a QA engineer how sprint planning usually goes and you will hear some version of the same story. The developers vote, the average lands somewhere reasonable, and the testing work gets squeezed into whatever is left at the end of the sprint. The estimate was never wrong for the code. It was wrong for the story.

This post is about giving testing effort a real place in planning poker: why it goes missing, how to estimate it, and what a team should do when QA's number is far away from everyone else's.

Why testing effort goes missing

Most teams estimate a story as a single number on a single scale, and most people in the room are developers. Even when a QA engineer votes, their card is one of six, and the average barely moves. Three habits make it worse:

• Developers estimate the change, not the verification. "It is a two-line fix" is a perfectly honest view of the code. It says nothing about the eight screens that render the field you just changed.
• Regression risk is invisible at the story level. A change to a shared component, a date format or a permission check can touch flows nobody mentioned in refinement.
• Test data and environments are not in the ticket. Setting up a customer with three currencies and an expired card can take longer than testing the feature itself.

None of this shows up in a single averaged number. It shows up in week two, when the story is "done except for testing".

Give QA its own column

The simplest fix is structural: keep QA's votes apart from everyone else's. In planning poker with role groups, each person votes as usual, but the reveal shows one average per role instead of one average for the room:

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

Nothing about the voting changes. Cards stay hidden until everyone has voted, nobody anchors anyone, and the QA engineer does not have to argue their number up from a footnote. The difference is that the 8 is now a headline, and the team has to talk about it.

How QA should size a story

A QA vote is most useful when it is based on the same few questions every time. Before you pick a card, walk through:

1. Scope of change. How many screens, endpoints, roles or integrations does this touch?
2. Data and setup. What accounts, records, feature flags or third-party sandboxes do you need, and do they exist today?
3. Regression surface. Which existing flows share code with this change and need a pass?
4. Automation. Will this be covered by new automated tests, existing ones, or only by hand?
5. Unknowns. Is there anything you cannot test yet, like a payment provider or an email in a real inbox?

If two or more of those answers are "a lot", it is a big story for QA no matter how small the code change is. Vote accordingly. A high QA vote is information the team needs, not pessimism.

When QA votes high

A reveal with Dev at 3 and QA at 8 is the most valuable moment in the meeting. Do not just revote until the numbers meet. Ask what is driving the gap, then pick one of these outcomes:

• Split the story. Ship the core change with focused tests now, and move the long tail of locales, browsers or edge cases into its own ticket.
• Change the approach. Sometimes a developer can make the change easier to test, for example by adding a seam for test data or keeping the old path behind a flag.
• Accept the real size. If testing really is the bulk of the work, the story is an 8. Plan it as one, so it does not quietly push something else out of the sprint.
• Add a task, not a debate. If the missing piece is test data or an environment, make that a separate, visible piece of work.

Then revote. The second round is usually much closer, because the team now shares the same picture of the work.

Reading the result

After the reveal, look at three things in order:

1. The spread between roles. In EstimateTask the confidence level drops to low and the reveal is marked high variance when role averages are far apart. That is the signal to discuss before accepting a number.
2. The distribution inside QA. Two QA votes of 5 and 13 tell a different story than two 8s.
3. The final estimate. EstimateTask uses the median across role groups, so one outlying group cannot drag the final number on its own, but it is still visible on the board.

Over a few sprints the voting history shows which kinds of stories the team keeps underestimating for QA. That is often the most useful retrospective topic you will find.

Practical tips for QA in estimation

• Bring a testing checklist to refinement. The five questions above fit on a sticky note.
• Vote on the whole story, not on "your part" only, unless the team agrees otherwise. Decide this once as a team so the numbers mean the same thing every sprint.
• Invite the people who know the risk. A support lead or a contractor who owns an integration can join a planning poker room as a guest from a share link and vote in the QA group, without an account.
• Revisit the estimate after testing. If the real effort was far off, note why. The pattern matters more than any single miss.

Try it with your team

EstimateTask keeps Dev, QA and DevOps averages side by side on every reveal, on every plan. The Free plan covers one project with up to five members and unlimited guest voters. Read why role-specific estimates beat one number, look through the features, or start free and give QA its own column at your next refinement.