Asymmetric Agile: Does your team have one velocity or multiple?

I've been noticing something in my day-to-day work and reading about it too: AI accelerated the pace of development, but that ended up creating an overload on QA. The natural result is that devs finish a few weeks ahead — not because something is wrong, but because each part of the process has its own rhythm.

What do you do in that situation? What any dev does: you take stories from upcoming sprints to avoid sitting idle. Stories the business hasn't formally prioritized, that QA hasn't seen, that the PO might not have finished refining. And the cycle repeats. You finish those too. You take more. The snowball keeps growing.

And the strangest part: nobody on the team sees it as a problem.

The manager looks at the burndown chart and it's green. The PO sees stories delivered. Dashboards say everything's going fine. From the outside, the team is productive. From the inside, the system is broken.

There's a widespread narrative that artificial intelligence is going to replace developers. In practice, at least for now, exactly the opposite is happening: AI makes us more productive, which means we produce more, which means more work in the pipeline, more pressure on QA, more meetings, more context to manage.

A study published just days ago in Harvard Business Review confirmed what many of us already felt before academia put it into words. Researchers from UC Berkeley spent eight months inside a 200-person tech company observing what happened when employees genuinely adopted AI. The result: they worked faster, took on more tasks, and extended work into hours that were previously personal — without anyone asking them to. The article is called "AI Doesn't Reduce Work — It Intensifies It" and the conclusion is clear: AI is generating more burnout, not less.

Because the tool accelerates only one part of the process. And that's exactly the trap.

I work with GitHub Copilot and Claude every day. They help me solve technical problems faster — the ones I know exactly how to solve but would take twice as long to implement by hand. Delivery gets faster. But QA can't change its timelines. Not because it's inefficient, but because validation has a human floor that no tool fully eliminates.

The Dev Stream accelerated, the Validation Stream didn't, and Scrum has no answer for that asymmetry.

Scrum was designed in a world where dev and QA had roughly comparable speeds. The sprint as a unit of time made sense because all the gears turned at a similar pace.

That's no longer the case. And it's not Scrum's fault — the context changed and the methodology hasn't evolved yet.

The clearest symptom is in estimation. In Scrum, a story has a size: X story points. But X for whom? For dev, a story might be 3 points. For QA, the same story is 8. Integration tests, edge cases, regressions, full user flows — validation has its own complexity that isn't captured anywhere in the current process.

The current estimation is a half-lie. We're measuring only half of the real work.

But the deeper problem isn't estimation — it's what happens next. Dev finishes, marks the story as done, and "throws it over the wall" to QA. QA picks it up from scratch, without context, and starts validating everything from the beginning. Not because they distrust the dev specifically, but because the process gives them no formal contract to lean on.

That's what Asymmetric Agile comes to change.

It's not about throwing out Scrum. It's about recognizing that the team no longer has one velocity — it has velocities — and designing the process around that reality.

The four pillars:

What stays the same: epics, refinement, retrospectives, t-shirt sizing as a base. It's not reinventing the wheel — it's adding the dimensions that are missing.

Let's say we're building a bicycle and the sprint story is: as a cyclist, I want front and rear lights so I can ride at night.

In classic Scrum, dev installs the lights in two days and hands off to QA, who has to validate: sufficient illumination, rear visibility, rain resistance, low battery behavior, cable interference with brakes, dynamo compatibility. What took dev 2 days takes QA 8. The sprint ends and QA is still on the lights.

In Asymmetric Agile:

The decision — C2 for the demo, C3 for the release — is explicit and conscious, not an informal last-minute workaround.

If the buffer fills up, dev doesn't take more stories: it invests that time improving C1 coverage, reducing QA's load instead of enlarging the bottleneck.

AI adopted only in the Dev Stream isn't an advantage — it's an imbalance. Asymmetric Agile doesn't resolve that imbalance by increasing QA's velocity, but by formally redistributing the validation responsibility between the two streams.

The team's velocity stops being a misleading number. The bottleneck becomes visible before it explodes. Dev can't throw a story over the wall to QA — that changes the conversation from "why are you taking so long?" to "what do you need from me to make C1 reliable?"

The result isn't a faster team. It's a team that knows exactly where it stands at every moment, that makes conscious decisions about what confidence level each feature needs, and that doesn't need three sprints of buffer to discover something is broken.

If you work in a team where dev is always ahead of QA, where estimation doesn't reflect the real work, and where dashboards say everything's fine while the team burns out: this is for you.

No need to rewrite the whole process overnight. Three concrete steps to start in your next sprint:

These three steps aren't the full Asymmetric Agile. They're enough to start seeing the asymmetry clearly.