For a good stretch of my career I was the tester who got handed a stack of stories marked “done” in the last two days of the sprint. I would work through them late, find the problems nobody had thought to ask about yet, and then sit in a standup where the quiet read on the room was that testing is what slows us down. I have been that person more times than I can count.
That stack of untested stories is not what it looks like. The end of the sprint is where the cost of the whole team’s earlier uncertainty finally comes due. Every vague requirement, every question skipped in refinement, every “we will figure that out later” waits until the last two days, and the tester is the one standing there when the total lands. It is not a speed problem. No amount of testing faster clears it.
What clears it is moving the cost earlier, so the uncertainty gets settled while it is still cheap and there is very little left to be surprised by at the end.
That shift, from a final checkpoint to a thread running through the whole sprint, is what people mean by the whole team approach to quality. The book Agile Testing by Lisa Crispin and Janet Gregory put it plainly: testing is an activity the whole team is responsible for, not a phase owned by one person at the end. Once the cost moves earlier, most of the bottleneck disappears on its own.
Why the late handoff hurts so much
The sprint where this goes wrong tends to look the same every time. A story gets pulled in, development starts, and the acceptance criteria turn out to be thinner than anyone realised.
I first see the working feature near the end of the sprint, find bugs and ask questions that should have been answered days ago, and now the team either rushes a fix or pushes the story to next sprint. Repeat that for a few sprints and the tester becomes the cleanup crew, permanently a sprint behind.
The reason it costs so much is that a defect gets harder to deal with the later you find it. A misunderstanding caught in refinement is a five-minute conversation. The same misunderstanding caught in production is a customer ticket, a hotfix, a regression, and a retro.
This is the whole logic behind shifting work to the left, earlier in the timeline. As DORA’s research on shifting left puts it, the goal is to address concerns “earlier in the software development lifecycle (that is, left in a left-to-right schedule diagram)” rather than bolting them on at the end.
Nothing about shifting left asks anyone to work faster. The work is the same, the people are the same. What changes is when the team learns the hard things, and a problem found on day two is always cheaper than the same problem found on day ten.
Start in refinement, not at the end
Refinement is the single highest-leverage place for a tester to spend time, because it is where the uncertainty gets created in the first place. Settle a question here and it never grows into a bill at the end of the sprint.
A feature that nobody can describe clearly cannot be built clearly, and it certainly cannot be tested clearly. The questions a tester asks before a line of code exists are usually the questions that save the sprint.
Before a story is pulled in, get into the habit of asking:
- What problem is this actually solving, and for whom?
- What are the main happy paths?
- What are the edge cases and the failure cases?
- What existing behaviour might this change or break?
- Does it need logging, analytics, or monitoring to be useful in production?
- What test data will we need, and where does it come from?
- What should be automated, and what is better explored by hand?
This is the heart of what the agile community calls the Three Amigos: business, development, and testing looking at the same story together before it is built.
The Agile Alliance frames the three perspectives as “What problem are we trying to solve?”, “How might we build a solution to solve that problem?”, and “What about this, what could possibly happen?”
That last question is yours, and asking it early is worth far more than asking it during a bug triage two weeks later.
When the story reaches me, I run it through the same short gut-check every time, whether or not there is anything built yet.
The questions I ask before we pull a story into the sprint:
- Does this story have acceptance criteria we could actually test, or just a title?
- What did the developer already check, and what are they most worried about?
- What data, permissions, or states does this touch that the demo will not show?
- What is our shared definition of done for this one, and is it written down?
- And before we call it ready: what would make us uncomfortable shipping it?
The clearest payoff shows up in acceptance criteria. A one-line story like “user can reset password” guarantees a conversation, but it will happen at the worst possible moment, when I open the feature on the last afternoon of the sprint.
Rewriting it as concrete, testable criteria before the story is pulled in surfaces the real decisions (does the link expire, what does an unregistered email see, does it leak whether an account exists) while they are still cheap to settle.
That refinement work, turning vague tickets into criteria a developer and a tester can both build against, is the most reliable way to prevent bugs before testing even begins, so I keep the full walkthrough of testable criteria, concrete examples, and the cancel-subscription case there rather than repeating it here.
Help shape the Definition of Done
If refinement decides what a story means, the Definition of Done decides what “finished” means, and QA should have a strong hand in writing it.
The Scrum Guide describes the Definition of Done as “a formal description of the state of the Increment when it meets the quality measures required for the product,” and it is explicit that during a sprint “quality does not decrease.”
That is a quality commitment baked right into the framework, and it is yours to help define.
A practical Definition of Done for a story-level increment might look like this. Each line names who carries it and what tells you it is genuinely finished, so “done” stops being a feeling:
- Owner: Dev. Acceptance criteria met and demonstrated. Done when: the team has seen each criterion working, not just heard it described.
- Owner: Dev. Unit tests added or updated where the logic warrants it. Done when: the new logic has tests and they pass in CI.
- Owner: Dev or QA. API or integration checks added for important behaviour. Done when: the key service behaviour has a check that fails if it breaks.
- Owner: QA. The relevant smoke test updated for any critical flow that changed. Done when: the smoke suite exercises the changed flow.
- Owner: QA. Accessibility basics checked (keyboard, labels, contrast). Done when: the flow is usable by keyboard and labels and contrast pass.
- Owner: QA. Verified on the browsers and devices the product actually supports. Done when: the supported matrix has been covered, not just one browser.
- Owner: Dev. Logging or analytics confirmed where the story requires it. Done when: the required events fire with the right payload.
- Owner: QA. No unresolved critical or high-severity defects. Done when: the open list has none, or the exceptions are written down and accepted.
- Owner: PM. Known limitations or release notes written down. Done when: anyone reading the notes knows what shipped and what did not.
Keep it honest. A Definition of Done that is impossible to meet every sprint will quietly be ignored, and an ignored definition is worse than none because it gives everyone false comfort.
Write the version your team can actually live up to, then raise the bar as the team gets stronger.
Test in slices, while the feature is being built
The biggest unlock for sprint flow is to stop waiting for a finished feature before testing anything. Most features can be broken into testable increments, and each one can be checked the moment it exists.
Take a new booking flow with five screens. You do not need all five screens to start finding problems. As pieces land you can:
- verify the API contract and its validation rules first
- check field-level validation on the UI shell as soon as it renders
- walk the happy-path navigation once two screens connect
- probe error handling and edge cases on each screen independently
- confirm the analytics events fire as the flow is wired up
Each slice you test early is a slice that will not pile up at the end. This is also where pairing earns its keep.
Pairing does not have to be a formal all-day affair. Often the most valuable version is a 20-minute conversation before everyone vanishes into their own tickets. The developer explains what is actually changing under the hood, you name the highest-risk areas, and together you agree what unit and API tests already cover versus what genuinely needs exploratory attention.
That single conversation prevents the most common waste in testing, which is two people checking the same path while a risky one goes untouched.
Reach for this kind of pairing whenever the work touches:
- payments, billing, or anything that moves money
- authentication, permissions, and roles
- data migrations
- third-party integrations
- complex calculations
- feature flags and release toggles
You are not there to approve every technical decision. You are there to make the risk visible to the whole team before it ships.
Write a small story test plan, right in the ticket
For any story with real risk, a short test plan in the ticket gives everyone a shared picture of the approach before you start clicking around.
The trick is to keep it short. If it reads like a formal document, nobody will read it.
## QA notes
Risk:
- New cancellation flow touches billing and customer trust.
Test focus:
- Active subscription, trial subscription, past-due subscription
- Cancellation from the account page
- Confirmation email and updated renewal date
- Analytics event fires once, with the right payload
Automation:
- API test: subscription status transition on cancel
- UI smoke test: happy-path cancellation
Manual / exploratory:
- Copy clarity on the confirmation screen
- Recovery if a user cancels then resubscribes
- Mobile viewport
Data needed:
- One active paid account, one trial account, one past-due accountNotice that each line names a specific behaviour to check, not a vague intention. “A past-due subscription can still be cancelled” tells you what success looks like; “test cancellation” does not.
When you write the plan, you are also doing the thinking that makes the testing itself fast.
Make automation part of the story, not a someday backlog
If automation is forever treated as “we will do it later,” later never arrives, and you accumulate a separate automation backlog that nobody has time for.
The healthier pattern is to attach the automation directly to the change that created the need for it. A story like “user can update their shipping address” carries its own automation tasks in the same ticket: an API test for the address-update validation, and an update to the checkout smoke test so it uses the edited address. That keeps your automated coverage growing alongside the product instead of lagging behind it as a cleanup project.
What you automate still has to earn its place. A flaky suite the team has learned to ignore is worse than no suite at all, because once people have to ask whether a failure is real, the suite has stopped giving them confidence. Automate the behaviour that would hurt most if it broke, keep it stable enough that a red run means something, and make that call in the story conversation, not in a cleanup project after the sprint.
Triage bugs quickly, and stop treating them all the same
Bug triage in an agile team should be fast and decisive. It goes a lot faster when every bug arrives already written up clearly, which is why I keep a shared bug report template handy.
For each bug, the team needs clear answers to a small set of questions:
- Is it reproducible, and on which environment?
- What is the user impact?
- What is the release impact?
- Is there a workaround?
- Is it a regression?
- Does it block the story, or can the story ship without it?
- Fix it now, fix it later, or accept it and move on?
The mistake that turns bug lists into noise is treating every defect with the same urgency. A typo in an admin-only tooltip and a broken checkout confirmation are not the same problem, and they should not generate the same release stress.
The fix is to keep two ideas separate:
| Describes | Example question | |
|---|---|---|
| Severity | How bad it is when it happens | Does the app crash, or is it cosmetic? |
| Priority | How soon it must be fixed | Does this block the release, or can it wait? |
These two do not always move together. A low-severity bug on a high-traffic page can still be high priority, and a high-severity bug in a feature nobody uses yet may not be.
Holding that distinction is most of what keeps triage calm instead of chaotic.
Quality is the whole team’s job, not QA’s veto
The most damaging version of the bottleneck is the one where QA is the single gate at the end, the one person who has to say yes or no with limited time and incomplete context.
That setup is unfair to the tester and bad for the product, because no individual can carry the full weight of quality at the very moment there is the least time to act on it.
A healthier split makes each part of quality visibly owned by the people best placed to own it.
| Quality dimension | Developers | Product | Design | QA |
|---|---|---|---|---|
| Code quality and unit coverage | ✓ | ✗ | ✗ | ~ |
| Expected behaviour and tradeoffs | ~ | ✓ | ~ | ~ |
| Usability and interaction quality | ✗ | ~ | ✓ | ~ |
| Test strategy and risk visibility | ~ | ✗ | ✗ | ✓ |
| Release readiness decision | ~ | ~ | ~ | ~ |
✓ primary owner ~ contributes ✗ not their lane
The bottom row is the important one. The release decision has no single owner with a check mark, because it belongs to the whole team.
Your job as the tester is to make the risk legible: here is what we tested, here is what we did not, here is what could go wrong, and here is my recommendation. Then the team decides together.
That is a far steadier place to stand than being the last person in the chain holding a rubber stamp.
A sprint rhythm that holds up
Put it all together and the tester’s contribution stretches across the whole sprint instead of bunching up at the end.
| Stage | What QA contributes |
|---|---|
| Backlog refinement | Clarify requirements, surface risks and edge cases, sharpen acceptance criteria |
| Sprint planning | Estimate test effort, flag blockers and data needs early |
| Development | Pair on risky work, test slices as they land, review logs and data |
| Code review and CI | Check automated coverage and read the test results, not just the green tick |
| Focused testing | Run the targeted manual and exploratory passes that automation cannot |
| Release | Share a short risk summary and a clear recommendation |
| Retrospective | Review escaped defects honestly and adjust the process |
You do not need to invent new ceremonies for any of this. Every one of these touchpoints already exists in a normal sprint.
The change is that quality thinking is present at each of them instead of being saved up for one frantic session.
Where this leaves you
Done well, agile QA does not feel like a handoff and it does not feel like extra process. It feels like quality is simply part of how the team works, present in the conversation before the code exists, woven through the build, and summarised honestly at release.
The earlier you get involved, the less dramatic testing becomes at the end, and the fewer late evenings anyone spends working through a stack of stories that should have been settled days ago.
If you want one concrete starting point for your next sprint, pick a single high-risk story and run the Three Amigos on it before it is pulled in. Get business, development, and testing in a room for fifteen minutes, ask “what could go wrong,” and write the acceptance criteria together.
That one habit, repeated, does more to remove the QA bottleneck than any tool ever will. The same logic scales past a single story, and it is the shape of a real quality strategy: quality is cheapest, and calmest, when the whole team owns it from the start instead of paying for it all on the last day.
Written by
Julia Pottinger
Hi, I'm Julia. I've been in QA for over a decade. I spend my days testing software and my own time building apps and games, and I write here to share what I learn, the practical, honest lessons you can actually use.
Comments 0
Share your thoughts, ask questions, or add to the conversation.