How to Estimate QA and Testing in Sprint Planning

“We’ll Test It Next Sprint” Is Quietly Killing Your Velocity

If your team is still treating QA as an afterthought in sprint planning, you’re not “agile” — you’re just doing mini-waterfalls in two-week chunks.

I’ve coached too many teams where:

• Stories are “done” in dev but sit untested for days
• Bugs discovered late blow up release dates
• QA is constantly “catching up” from the previous sprint

Then leadership wonders why velocity is unstable and predictability is garbage.

The root cause is almost always the same: testing is not properly estimated, planned, or owned in the sprint.

Let’s fix that.

---

Why QA Estimation Is So Messy (And Why It Matters)

The Invisible Work Problem

Most teams underestimate testing because they only estimate coding effort. Everything else is treated as “overhead”:

• Test case design
• Exploratory testing
• Regression checks
• Environment setup and data prep
• Fix–retest loops

None of that is free. If it’s not estimated, it gets squeezed — and quality is the first thing to break.

A common pattern:

• Story estimated as 3 points based on development only
• QA starts late, finds issues
• Devs context-switch back from new work
• Story spills into the next sprint

Your board says 3 points. Reality was closer to 5–8.

QA Is a Throughput Constraint, Not a Checkbox

In many teams, QA is the bottleneck. Here’s a stat from multiple orgs I’ve worked with:

On average, 40–60% of cycle time is spent after development is “done”.

If you don’t estimate QA, your true capacity is fantasy. You’re planning 40 points as if you had 40 points of dev capacity and 40 points of QA capacity. You don’t.

When QA is overloaded:

• Devs start “helping” with testing in an unstructured way
• Bugs leak to production
• Product loses trust in estimates

So let’s stop pretending testing is free and bake it into sprint planning properly.

---

Step 1: Redefine “Done” to Include Testing — For Real

Your Definition of Done Is Your Estimation Contract

If your Definition of Done (DoD) doesn’t explicitly include testing activities, you will systematically under-estimate.

A serious DoD for a feature story should include:

• Unit tests written and passing
• Functional acceptance criteria tested
• Relevant regression checks executed
• Bugs found in this work are fixed or explicitly tracked
• Tested in an environment representative of production
• Test data created/updated as needed

Now here’s the important part:

You estimate the story based on this full Definition of Done — not just the coding.

If your team is saying “3 points if we ignore testing, 5 points if we include it,” the answer is 5. Every time.

Make QA a Shared Responsibility

Drop the “dev story” vs “QA story” nonsense for feature work.

• One story
• One DoD
• One estimate that includes both dev and test
• Shared ownership across the team

If you currently split feature and testing into separate tickets, you’re optimizing for reporting, not delivery.

---

Step 2: Bring QA Fully Into Sprint Planning

If QA Isn’t Estimating, You’re Guessing

Having developers estimate testing effort alone is like having product estimate database refactors.

In sprint planning:

• QA should speak first on testing complexity and risk
• Devs should then adjust estimates based on implementation complexity
• The final estimate reflects both perspectives

Questions QA should ask in planning:

• How risky is this change to existing behavior?
• How many user flows could this impact?
• What environments and devices do we need to cover?
• Are there third-party integrations or dependencies?
• How much data setup is needed to test this properly?

When QA is silent during estimation, you’re not doing agile planning — you’re doing wishful thinking.

Estimate Testing Using Risk, Not Just Size

Two stories with the same dev effort can have wildly different testing effort:

• A new button on an isolated admin page
• A small change in authentication logic used across the product

Both might be “2 points” for dev, but testing effort is not the same.

Add a quick risk score during planning (low / medium / high) that influences your estimate:

• Low risk: simple UI, no complex flows, minimal regression
• Medium risk: affects a few flows or key data paths
• High risk: auth, payments, pricing, shared libraries, or critical workflows

High-risk stories should almost always get more points to reflect heavier testing and regression.

---

Step 3: Convert Testing Work Into Concrete Tasks

Vague Testing = Underestimated Testing

“QA will test it” is not a plan.

For each story, break down testing into explicit tasks in your sprint backlog. For example:

Story: User can reset password via email

Tasks:

• Design test cases for password reset flows
• Functional testing: happy path + edge cases
• Negative testing: invalid tokens, expired links
• Regression: login, signup, profile update flows
• Cross-device/browser checks
• Data setup and cleanup

Now you can:

• See the real scope of work
• Spot overloaded QA before the sprint explodes
• Let devs pick up test tasks when they have capacity

Use Time-Bounded Exploratory Testing

Exploratory testing is essential — but it’s also where estimates go to die if you’re not careful.

Treat it like this:

• Add a specific task: “Exploratory testing for story X”
• Timebox it: e.g., 1–2 hours for low-risk, 3–4 hours for high-risk
• Capture findings as notes or charters

This keeps exploratory work visible and bounded, instead of a mysterious sinkhole.

---

Step 4: Use Data to Calibrate QA Estimates

Track Where Your Time Actually Goes

You don’t need heavy tooling — just start capturing a few key things per story:

• Dev effort vs. test effort (rough hours or % split)
• Number of test cycles (test → fix → retest)
• Bug count found during story testing vs. after release

Patterns you might find:

• “Our ‘simple’ backend changes cause 3x more regression bugs.”
• “Stories touching payments always require an extra test cycle.”
• “Mobile UI changes take 50% more test time than web.”

Use this data to:

• Adjust story point baselines
• Flag work that needs higher estimates
• Push back on “it’s just a small change” narratives

Stabilize Velocity by Including QA in Capacity

Most teams calculate sprint capacity like this:

• “We did 30 points last sprint, let’s aim for 32 this one.”

But if last sprint:

• Dev was at 80% capacity
• QA was at 130% capacity

Your 30 points were a fluke, not a baseline.

Instead:

• Look at how many stories were fully done (including testing)
• Use that as your reference, not just total points
• Adjust your planning if QA is consistently overloaded

If QA is the bottleneck, your true capacity is QA capacity, not dev capacity. Pretending otherwise is how you end up with half-done stories every sprint.

---

Common Mistakes When Estimating QA in Sprint Planning

1. Estimating Only Development, “Squeezing In” Testing

This is the classic failure mode.

Symptoms:

• Stories marked done on the last day with “QA to follow”
• QA rushing or skipping regression
• Bugs discovered right before release

Fix:

• Refuse to mark stories “done” until testing is complete
• Estimate stories as a whole, not dev-only

2. Splitting QA into Separate “Testing Stories”

I see this a lot in Jira:

• Story A: “Implement new login flow”
• Story B: “Test new login flow”

On paper, it looks clean. In reality:

• Testing is de-prioritized when crunch time hits
• Story A is reported as “done” while risk is still high
• Metrics like velocity and throughput become meaningless

Fix:

• One story per feature, including both dev and test
• Only use separate bugs/tasks when issues are found

3. Pretending Regression Is “Outside” the Story

Teams often say:

• “We’ll cover regression in a separate regression cycle”
• “We don’t estimate regression, it’s part of QA’s job”

Result:

• Regression gets rushed or skipped
• QA becomes a permanent bottleneck
• Releases are stressful and unpredictable

Fix:

• Include relevant regression testing in each story’s estimate
• Keep a regression checklist per area and attach it to stories

4. Not Accounting for Environment and Data Pain

If your test environments are flaky or data setup is painful, that’s real work.

Common time sinks:

• Waiting for builds to deploy
• Fixing broken test environments
• Creating complex data scenarios manually

If you don’t estimate this:

• Sprints slip
• QA gets unfairly blamed
• Testing is constantly rushed

Fix:

• Explicit tasks for environment setup / data prep
• Track and surface this overhead as technical debt to be addressed

---

Practical, Tactical Ways to Estimate QA Better

1. Use Planning Poker With QA Fully Participating

Don’t let only devs vote.

During planning poker:

• QA calls out testing complexity and risk
• Devs call out implementation complexity
• If QA consistently votes higher, talk about why

This is where tools like ScrumPoi are useful:

• Anonymous voting reduces anchoring (e.g., everyone following the loudest dev)
• No signup means you can quickly spin up a session with dev + QA + PO

2. Add a Simple “Testing Complexity” Scale

Alongside story points, tag each story with testing complexity:

• T1 – Minimal: small UI change, no regression risk
• T2 – Moderate: affects 1–2 flows, limited regression
• T3 – Heavy: core logic, multiple flows, broad regression

Use this to:

• Check that your T3 stories aren’t estimated as tiny
• Balance your sprint so you don’t overload QA with too many T3s

3. Reserve Capacity for Bug Fixing and Retesting

Your sprint will have bugs. Pretending it won’t is how you blow up estimates.

Practical approach:

• Reserve 10–20% of team capacity for bug fixing and retesting
• Track how much of that buffer you actually use
• Adjust over time based on your defect rate

This avoids the “we planned 10 stories but spent half the sprint fixing bugs” surprise.

4. Move Testing Earlier With Testable Slices

If testing always happens in the last 2–3 days of the sprint, you will never estimate it well.

Change how you slice stories:

• Aim for vertical slices that can be tested end-to-end early
• Avoid stories that are “backend only” with no testable output
• Start testing as soon as the first slice is ready, not when everything is coded

The earlier QA can touch the work, the more predictable your estimates become.

5. Automate the Boring, Estimate the Rest

Don’t hand-wave automation as “someday”.

For high-churn areas:

• Add tasks in the story: “Add/Update automated tests for X”
• Estimate that work explicitly
• Over time, regression effort drops and your QA estimates stabilize

Automation is a capacity multiplier — but only if you treat it as real work during planning.

---

Tools Can Help, But Discipline Matters More

You don’t need a massive tooling overhaul to estimate QA better. You need:

• A real Definition of Done that includes testing
• QA actively involved in planning and estimation
• Explicit testing tasks per story
• A feedback loop from actual time spent to future estimates

Collaboration tools can make this smoother. For example, using ScrumPoi for planning poker and retrospectives gives you:

• Anonymous estimation so QA can safely challenge lowball estimates
• Fast, no-signup sessions so you can involve the whole team
• Jira integration to tie estimates directly to your backlog

But no tool will fix a culture that treats QA as an afterthought.

---

Wrap-Up: If You Don’t Estimate Testing, You’re Not Estimating

If your sprint planning doesn’t explicitly account for QA and testing:

• Your velocity is fake
• Your predictability is fake
• Your “Definition of Done” is fake

The teams that ship reliably high-quality software aren’t magically better at coding. They’re better at planning the whole flow, including testing.

Start next sprint by:

• Updating your Definition of Done
• Bringing QA front and center in planning
• Turning vague “QA will test it” into concrete tasks and estimates

You’ll ship fewer surprises, fewer late nights, and a lot more genuinely done work.