If you’ve worked in software delivery for any length of time, you’ve probably seen the same Jira board pattern again and again:
To Do → In Progress → In Test → Done.
It’s common. It’s familiar. And because of that, it feels natural—maybe even necessary. The flow of work seems logical, doesn’t it? Development happens, testing happens, and then we’re done. But here’s the thing: familiarity doesn’t always mean it’s working the way we think it is.
Lately, I’ve been encouraging teams to question that assumption. To ask:
What exactly is the “In Test” column doing for us? And, more importantly, what might it be doing to us?
At first glance, it looks useful. It provides visibility. It signals that the story is done with development and has moved into QA. It gives testing its own lane. It seems like a clean, organized way to track progress. But when you zoom out and examine the broader system of delivery, that column starts to reveal deeper issues—issues that can stall the flow of work, obscure ownership, and reinforce silos.
It Obscures Responsibility
The first problem I’ve noticed with “In Test” is that it muddles accountability. Once a story moves to “In Test,” developers often assume their work is done and they move on to the next ticket. But that leaves the story in a state where no one is truly responsible for pushing it across the finish line.
QA is often left trying to pick up the pieces, but without the full context or a clear handoff. And the result? The story stalls. Work gets caught in a state of limbo between “In Progress” and “Done,” and no one feels fully accountable for making sure it actually gets tested and validated. It’s like a team that moves on to the next play while the last one is still hanging in the air.
It Breaks Flow
Agile is meant to support continuous, smooth delivery of value. In a well-functioning system, work flows through each stage without unnecessary interruptions or delays. But “In Test” often serves as a stopping point, breaking that flow. The story is no longer actively being worked on; it’s just sitting there, waiting for testing to finish.
The problem with that is the visual illusion of progress. When a story moves to “In Test,” it looks like it’s nearly done. But just because it’s further to the right on the board doesn’t mean it’s actually closer to delivery. The work in the “In Test” column could be sitting there for days, creating a bottleneck that slows everything else down. Teams might mentally check off that story, thinking it’s done, but in reality, there’s still work left to do. And that lack of clarity on where the work truly stands can cause unnecessary delays, confusion, and frustration across the team.
It Reinforces Silos
“In Test” becomes shorthand for “not my problem anymore.” Instead of encouraging developers and testers to collaborate early and often, it reinforces a linear mindset. Testing turns into a downstream activity rather than an integrated part of the work. This split creates frustration on both sides, delays feedback, and drives rework. It’s the exact opposite of what cross-functional teams are meant to be.
We should not treat testing as something that happens after development. It should be woven into the process, not tagged on at the end. That means building shared definitions of done. It means writing acceptance criteria together. It means collaborating on automation strategies and baking in validation from the beginning.
This shift will take time. It’s not something you can just flip a switch and expect it to work. It will take a concerted effort to change the way teams think about testing and quality. It will require coaching, advocacy, and a mindset shift that prioritizes shared responsibility and continuous feedback over isolated phases and handoffs.
It’s not going to be easy. But it’s worth it. Because the teams that embrace this kind of change tend to ship faster, with higher quality, and with far less frustration.
