The Hidden Cost of Asking QA to Test Tickets Instead of Journeys
A better process for developers, QA, product managers — and the product itself.
There is a quiet inefficiency that lives inside most engineering sprints. It doesn’t announce itself loudly. It shows up as a stale ticket. A build that nobody is quite sure is the right one. A QA engineer asking, “which part of this flow am I testing again?” — for the fourth time this week.
If you’ve sat in a sprint review and wondered why the burndown chart looks like a flat line until the last two days, you’ve met this inefficiency. This post is about naming it, understanding it, and fixing it.
The Setup: When Good Teams Build Bad Processes
Let’s start with something important: the process we’re about to critique was never designed to fail. It emerged organically from reasonable instincts.
Product managers create epics. Engineers break them into smaller, workable tickets. Small tickets move faster. Parallelism is achieved. Individuals own their tasks. It all makes sense on a whiteboard.
Take a common example — a feature to show a promotional banner in a mobile app. Even something this contained typically decomposes into:
- API integration
- API parsing
- Experience API — remote config variable creation
- UI component
- Error states
- Variant B flow structure
- UI tests + Unit tests
A group of two to four engineers picks these up and runs. One takes the API work, another takes the UI component, someone else handles the config. Progress happens simultaneously. Tickets start moving across the board. Things feel fast.
And then they arrive at QA.
Where the Wheels Come Off
Here’s what actually happens in practice once those tickets hit testing.
Each developer, after finishing their piece, spins up a local build and brings it to the QA engineer. “Can you verify this?” The QA engineer — one person, shared across the team — is now context-switching between multiple partial builds, each representing a slice of a journey she has never seen in full.
She needs to ask: What does this ticket do? What should I look for? What’s been built before this? What comes after?Each verification requires a small knowledge-transfer session. Each session takes time neither party has.
By the time all seven tickets have been individually signed off and merged, the QA engineer has touched the same feature seven times — and still needs to test it once more, end-to-end, as a complete user journey. Because that is what goes to production. Not seven isolated pieces. One experience.
The costs accumulate quickly:
For QA: Constant context-switching between partial, disconnected pieces of work. Time spent understanding scope and communicating with individual developers before every single verification. Testing a sub-section of a journey that tells you very little about whether the journey itself works.
For developers: Tickets stall waiting for QA availability. PRs go stale for days. There’s friction between the pace of building and the pace of review. The sprint board doesn’t reflect actual progress, because “done” requires a sign-off that hasn’t arrived yet.
For product managers: The burndown chart looks catastrophic — flat through the week, then a flurry of moves at the end. It’s hard to predict delivery. It’s hard to see whether a feature is actually close to complete or still weeks away.
For the product itself: Bugs found late in the individual ticket cycle get reassigned back into the sprint as new items, disrupting everything and everyone. Half-finished work sometimes gets pushed to QA prematurely — just to “get it moving” — which wastes review time on something that isn’t ready.
None of this is anyone’s fault. It is a process problem.
A Different Model: The Feature Branch + Feature Champion
The new approach is built on two structural changes that reinforce each other.
Change one: All sub-tickets merge into a dedicated feature branch — not main, not develop.
When a developer finishes their piece of work, the PR doesn’t go straight to the main codebase. It goes into a feature branch — a shared base branch created specifically for this epic or flow. The API integration goes in. The UI component goes in. The config variable, the error states, the tests — all of it accumulates in one place, progressively, as each developer finishes their work.
Nothing in this branch is considered tested or production-ready. It is a staging area. A place where all the pieces come together before anyone calls it done.
Change two: A Feature Champion (FC) is assigned for each feature.
The FC is a single engineer on the team who takes ownership of the feature branch. They are the point of contact between the engineering group and QA. Their responsibilities are clear:
- Maintain the feature branch and keep it coherent
- Generate builds from the cumulative branch once enough work has been integrated
- Be the one person QA talks to about scope, context, and what to test
- Triage and facilitate any bug fixes that come back from testing
- Raise the final PR from the feature branch into main or develop once QA has given the green light
The FC doesn’t necessarily write more code than anyone else. They are the connective tissue between the team and the testing process.
What QA Testing Looks Like Under This Model
Instead of receiving seven separate builds across two weeks, the QA engineer receives one build — assembled by the FC — that contains the complete feature, all variants, all error states, and all the integration points working together.
She can now test the actual user journey. She can walk through the flow as a customer would. She can verify that the API and the UI component and the error handling all work together, not just that each one worked in isolation.
When she finds a bug, it is raised against the feature epic — not reassigned to an individual ticket. The FC assesses it, routes it to the right engineer, and manages the fix. QA doesn’t need to track where it came from. The PM doesn’t have a mystery item appearing on the sprint board mid-cycle.
The result is a sign-off that actually means something: this feature, in full, is ready.
What Changes for Each Stakeholder
For QA engineers: Fewer, more meaningful testing sessions. Full context, provided by a single point of contact. The ability to test what customers will actually experience, rather than isolated implementation details. More time for exploratory testing, edge cases, and the kinds of quality checks that require judgment rather than just instruction-following.
For developers and engineers: Tickets move faster because they no longer block on individual QA sign-offs. Work merges into the feature branch on the developer’s timeline. The FC creates a healthy separation between the pace of building and the pace of testing, so neither bottlenecks the other. Developers retain autonomy over their own tasks while contributing to a shared goal.
For product managers: The sprint board becomes meaningful again. Individual tickets move as work completes. The final QA sign-off is on the full journey, which is also the product manager’s moment to verify the feature meets the original intent. Burndown charts reflect actual progress rather than the artificial rhythm of waiting-for-QA.
For the codebase: Main and develop remain protected throughout. Nothing gets merged into the production path without full QA approval of the complete journey. The feature branch acts as a natural gate, and the final PR from feature branch to main is clean, tested, and peer-reviewed.
On the Role of the Feature Champion
It’s worth pausing on this role, because it’s easy to misread it.
The FC is not a bottleneck. They are not an approver who every developer must go through before doing anything. The sub-tickets still get built in parallel. Engineers still work at their own pace. The FC’s job kicks in at the integration layer— when it’s time to bring things together and hand them to QA.
Think of the FC as a project owner in miniature. They hold the context. They know which pieces are in, which are pending, and when the branch is ready for a full build. They are the person who can answer, without hesitation, “what is this feature supposed to do, and is it doing it?”
Part of maintaining that confidence is enforcing a simple, non-negotiable rule for the feature branch: every merge must pass CI. Tests green, branch healthy, no knowingly broken states. The FC is the guardian of that standard. If something lands in the branch that breaks it, the FC coordinates the fix before anything else moves forward. This isn’t bureaucracy — it’s what makes the eventual QA build trustworthy.
On a team of two to four engineers, rotating the FC role across features ensures the responsibility is shared and the skill is developed. It is a natural step in the growth of any engineer who wants to develop broader ownership skills.
Defining “Done” — And Meaning It
One of the subtle benefits of this model is that it forces a conversation most teams avoid: what does done actually mean?
Under the old process, “done” is ambiguous. A ticket might be implemented, locally tested, and sitting in a PR — but not QA-signed, not merged, not truly complete. That ambiguity is part of why sprint boards lie.
This process creates two explicit, distinct definitions that the whole team should agree on upfront:
Done for Development
- Implementation is complete
- Code has been peer reviewed
- Local testing has been performed
- The PR has been merged into the feature branch
- CI is passing
Done for Release
- All development work is integrated into the feature branch
- The FC has generated a cumulative build
- QA has validated the complete user journey
- The product manager has signed off on the feature
- The PR from feature branch to main/develop has been raised and approved
A ticket reaching “Done for Development” is genuinely celebrated — it moves on the board, it contributes to the burndown, it represents real progress. But it doesn’t mean the feature ships. Only “Done for Release” does that. Keeping these two states clearly separated removes the ambiguity that makes sprint metrics meaningless and handoffs messy.
The Bigger Picture
There is a useful principle hiding inside this process change: test the thing that will ship, not the thing that was built in isolation.
Engineering teams are good at decomposing work. That’s a strength. Small tickets, parallel development, individual ownership — these things genuinely help teams move quickly through complex problems. The mistake is assuming that the testing process should mirror the build process.
Building is inherently decomposed. Testing, at the point where it matters most, should be integrated.
The process described here doesn’t remove the benefits of small tickets and parallel development. It preserves them at the build stage and adds the integration layer that was always missing at the test stage.
The result is a team where QA’s time is spent on the work that QA does best: finding the problems that only appear when everything is running together. And a sprint board that actually tells you where you are.
Time is precious. The way we choose to spend it as a team is a design decision — one worth making deliberately.
