'Dev is done' isn't done: dev and QA are one team

Every few sprints, the same sentence lands in our planning meeting. A developer picks up a user story, sizes it, and then says: "Okay, dev's done — now QA needs its own estimate."

I used to let it slide. Now it stops me every time. Because buried in that one sentence is a belief about how software gets built, and the belief is wrong.

The split that keeps showing up

Here's the pattern. We're pointing a story. The dev work gets an estimate. Then, almost as a separate line item, someone asks how many points QA needs — as if testing were a different order at the same restaurant, cooked in a different kitchen, billed separately.

It sounds efficient. Two teams, two estimates, two chunks of work. Everyone knows their lane.

It's not efficient. It's a quiet admission that we think the feature is finished before anyone has tried to break it. The dev side is "done." QA is the thing that happens to it afterward, if there's time.

"Done" was never "it works on my machine"

I keep coming back to what "done" actually means, because most of the friction disappears once a team agrees on that.

The 2020 Scrum Guide is blunt about it. "Within a Scrum Team, there are no sub-teams or hierarchies." The team is cross-functional. And "the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." There's no clause that says the developers ship the code and someone else is on the hook for whether it works.

The same guide says "the Developers are required to conform to the Definition of Done" — and the moment a backlog item meets that definition, an Increment is born. Not before.

On our team, a story isn't done until three things are true:

• the code is written and reviewed
• it's deployed where it actually needs to run
• someone has tried to break it, and it held

So a story where the code is written but nothing has been verified isn't "dev done, QA pending." It's just not done. There's one state, and it's binary.

That's the part people skip. "Done" is a team-level word. It was never a developer-level word.

Two mindsets walk into a feature

Here's where I want to be fair, because the split usually comes from a good place.

A developer who just built a feature has a specific kind of confidence. They designed it, they wrote it, they watched it work. They own it. When they say "it's done," they mean "I made this thing do what the ticket asked, and I saw it happen." That's not arrogance. That's the honest experience of building something and watching it run.

QA lives somewhere else entirely. A tester picks up the same feature and the first thought isn't "does it work," it's "what if." The questions come fast:

• What if this field gets a value nobody expected?
• What if the user runs these steps out of order?
• What if the network drops halfway through the save?

Those are two different relationships with the same code. The builder's instinct is to confirm it works. The tester's instinct is to find where it doesn't. Both are correct, and both are necessary. The problem is never that these mindsets exist. The trouble starts when we let them turn into two teams with two estimates instead of one team with one feature.

There's also a plain human reason the split fails. You can't easily test the assumption you didn't know you were making. The developer who decided that field would always be a string isn't hiding anything — they simply can't see the gap from inside their own design. That's not a knock on developers. It's the whole reason a second pair of eyes with a different instinct is part of the job, not a favor.

"What if" isn't pessimism — it's the job

Let me make the "what if" concrete, because from the outside it can look like QA is just being difficult.

A while back we had a feature that saved a user setting. The code was clean, the happy path was flawless, the demo was perfect. Dev was, by every reasonable measure, done.

Then someone on QA asked the question that only a tester asks first: what happens if this property comes in as a boolean when the schema expects a string? Nobody had designed for that. So we tried it. The record didn't error loudly. It didn't throw. It quietly failed to save the way we expected, and a real user's data would have been lost without a single alarm going off.

That's the whole value of the mindset in one example. Nobody wrote that scenario into the ticket. It came from a person whose job is to ask "what if I put the wrong type here" before a customer does it by accident. The developer built exactly what was asked. QA found the thing nobody thought to ask about. Same team, same feature, one saved outcome.

Shipping faster made the gap worse

You'd think that in 2026, with AI writing large chunks of our code, this whole tension would ease. It's done the opposite.

The 2025 DORA report frames AI as "an amplifier" that magnifies whatever strengths and weaknesses a team already has. And the headline finding is uncomfortable. AI adoption raised delivery throughput while correlating with more instability: more change failures, more rework, longer recovery. Teams got faster and less stable at the same time. If a team already treated testing as a separate estimate, AI didn't fix that. It just pushed more untested code at the same undersized safety net.

Why? Because AI speeds up the part that was already fast — generating code — while testing, review, and QA are the downstream bottleneck that can't absorb the extra volume. Push more code through a team that treats verification as a separate estimate, and the seam I described earlier doesn't shrink. It widens.

That's also why the World Quality Report 2025-26 now talks about quality as a leadership concern rather than a testing team's chore. When code is cheap to produce, the scarce thing is confidence that it actually works. And confidence is exactly what the "what if" mindset produces.

One feature, one team, one definition of done

So here's where I've landed, and what I try to hold the line on in planning.

We don't estimate a dev story and then bolt a QA story onto it. We estimate a feature. The estimate includes building it, deploying it, and proving it works — because none of those are optional, and none of them belong to a separate team. If it isn't tested, it isn't done, and an untested story sitting at "dev complete" is just work in progress wearing a finished label.

That reframe changes the meeting. Testing stops being a line item someone tries to trim when the sprint runs tight. It becomes part of what "done" costs, the same way you'd never estimate a feature and then ask for separate points to make the code compile.

It also changes who owns a bug. When the estimate covered the whole feature, a defect found in testing isn't QA "sending it back" to dev. It's the team discovering the feature isn't done yet, together, before a user does. Nobody has to defend their half. There aren't halves. There's a story that's either done or it isn't, and everyone in the room shares that number.

This is the same thread I've written about before — that good building starts with QA thinking, not as a phase you tack on but as a way of approaching the work from the first line. And it's why, as I argued after AI Con 2026, QA got harder, not easier. The faster we ship, the more the "what if" mindset earns its seat.

Two mindsets, one team. The builder who makes it work and the tester who tries to break it aren't opponents negotiating separate estimates — they're the two halves of the same promise to the person who'll actually use the thing. A feature isn't bulletproof because one person was certain it worked. It's bulletproof because someone asked what if, and the whole team owned the answer.

---

Does your team split dev and QA into separate estimates? I'd genuinely like to hear how you handle that conversation in planning — get in touch.