Should QA Estimate Separately?

Every team with dedicated testers hits this question sooner or later. When a ticket is estimated, does QA size just the testing, as its own number? Or does everyone, testers included, size the whole ticket, as one number?

Both answers are common, and both have serious people behind them. The right one depends less on agile theory than on where your team's work actually gets stuck.

The case for one number

The strongest argument for a single estimate is that a ticket isn't done until it's tested. Mountain Goat Software puts it bluntly: an estimate on a backlog item "needs to represent the total effort to deliver that item. It's not an estimate of all the work except database changes or all the work except testing."^[1]

The Scrum Guide points the same way. It has one role, Developers, for everyone who builds the increment, and says that "within a Scrum Team, there are no sub-teams or hierarchies." The people doing the work size it together^[2].

One number also has practical benefits:

• No hand-off mindset. Separate numbers make it easy to think of a ticket as "dev done, now it's QA's problem." One number means the team owns it until it ships.
• Velocity means one thing. The team's velocity counts finished, tested work. Nobody has to decide whether to add QA points to dev points.
• Testers shape the whole estimate. A tester who knows the payments flow is fragile can push the whole ticket up, not just their slice of it.

The case for separate numbers

The strongest argument the other way is that testing effort doesn't scale with build effort. A Thoughtworks article gives the classic example: supporting a customer search screen on two new browsers "might be a 1 point development effort," but it's a lot more from a testing perspective^[3].

It goes the other way too. A large refactor behind a feature flag can be a lot of code with very little new to test. One number blends those two efforts, and the blend hides the case where one side is far bigger than the other.

Separate numbers also help when:

• QA is the bottleneck. If three developers share one tester, the sprint isn't limited by dev points. A separate QA number shows how much testing the sprint asks for before the tester is buried in week two.
• The tester's view gets drowned out. With five developers and one tester voting on one number, the tester's "this needs a full regression pass" is easy to overrule. A separate number can't be outvoted.
• You plan or report testing on its own. Some organizations track test effort separately, or share testers across teams. A separate number gives them that directly.

Same tickets, two ways

Here's how three tickets might be estimated each way:

The whole-ticket numbers are reasonable. But only the separate numbers show that the first ticket is mostly testing and the second is mostly building. That difference matters if your one tester has three tickets like the first in the same sprint.

What each choice costs

Neither option is free:

The agreement row is easy to miss. With one number, a ticket only settles when developers and testers agree. That's more conversations, though often useful ones: a developer's 3 and a tester's 8 is exactly the gap described in why estimates disagree.

How to decide

Ask these questions about your team:

1. Is testing usually the bottleneck? If tickets regularly wait for QA, estimate separately so the sprint plan shows it.
2. Does testing effort often differ from build effort? If a ticket's testing is often much bigger or much smaller than its build, separate numbers show it. If they usually move together, one number loses little.
3. Do testers and developers pair, or hand off? Teams where testers work alongside developers from the start usually find one number natural. Teams with a handoff often find separate numbers more honest, at least for now.
4. Does anyone outside the team need testing effort on its own? If so, estimate separately.

If most answers point one way, go that way. If they're split, start with one number and switch if testing keeps being under-planned. It's easier to add detail than to take it away.

Not every ticket needs QA

There's a third question hidden inside this one: does QA estimate every ticket? For a team where most tickets get the same testing, the answer is yes. But a team with a lot of internal tooling, config changes or spikes may want QA to estimate only the tickets that need dedicated testing, and leave the rest to the developers.

How Async Pointing Poker handles it

Async Pointing Poker supports both approaches, as two session settings:

• QA estimate mode. In separate mode, QA sizes only the testing, and each role group (Frontend, Backend, QA, ...) agrees among itself and keeps its own number. In integrated mode, everyone tagged on the ticket, QA included, sizes the whole ticket, and all of them must agree on one number. If they don't, the Scrum Master sets it.
• QA applies to all tickets. On, QA estimates every ticket. Off, QA only estimates tickets tagged with QA.

The Scrum Master guide walks through both settings, with the same votes settled under each mode.

The short version

• One number treats a ticket as done only when it's tested, and keeps the team from handing off. It's the Scrum default.
• Separate numbers show testing that doesn't scale with the build, and show a QA bottleneck before it bites.
• Choose based on where your work gets stuck, not on principle.
• Unsure? Start with one number. Switch if testing keeps being under-planned.

Sources

1. ↩Mountain Goat Software, “3 Roles That Need to be Involved in Agile Estimating with Planning Poker” — an estimate covers all the work, including testing
2. ↩Ken Schwaber and Jeff Sutherland, “The Scrum Guide” (2020) — no sub-teams; the Developers doing the work size it
3. ↩Anand Vishwanath, “All about the Point” (Thoughtworks, 2014) — the two-new-browsers example