Project Management for QA Projects

QA's problem is timing, not effort

Most project tools are built around a team that plans its own work. QA rarely gets that luxury. A build lands, a feature freezes, a release window closes in, and the testing work arrives on QA's desk on someone else's schedule, in whatever volume engineering happens to produce that week. Some weeks it's a trickle. The week before a release it's a flood, and the flood always seems to land on a Thursday.

The failure mode that follows is familiar: everything gets tested at once, badly, because there's no way to say "we're already full" before agreeing to take on the next thing. Regression coverage gets cut first, because it's the least visible corner to cut, right up until it's the reason a release goes out broken.

ShipSprint doesn't change when work arrives. Nothing can; QA is downstream by definition. What it changes is whether QA has a real limit it can point to, and whether what's already in flight is visible to the people upstream who keep adding to it.

One stream, honestly triaged

Bug reports and test requests land in the same triage inbox as anything else. There's no separate bug-only queue that engineering's requests skip past. That's deliberate: QA's actual problem is competing demands on the same limited hours, and a system that pretends bugs live somewhere separate just hides that competition instead of resolving it.

Severity, in ShipSprint, is not a rigid field with five levels and a workflow attached. It's a priority signal a team applies the way they already talk about it, and the WIP limit on QA's column is what actually enforces the trade-off. A "critical" bug that jumps the queue means something else in that column waits, and that's visible immediately rather than absorbed into someone's unpaid evening.

QA's board sits downstream of engineering's by design. A card doesn't reach QA's column until it's actually ready, so testing effort isn't wasted verifying half-finished work, and the WIP limit on QA's side of the board is the honest cap on how much can be in verification at once, regardless of how much engineering ships in a given week. In practice that's the thing that changes for a QA lead switching to ShipSprint: the queue stops being a feeling and starts being a number everyone can see filling up.

The week before a release, specifically

This is where QA's problem is sharpest. Feature freeze hits Monday, and by Tuesday afternoon the triage inbox has three times its normal volume: bug reports from internal testing, edge cases someone finally got around to checking, a handful of "can you also verify this while you're in there" requests that weren't really bugs at all. In a tool with no real limit, all of it gets pulled onto the board at once, because saying no in the moment feels like the thing most likely to cause a missed release.

With a WIP limit that actually holds, that instinct runs into a wall early rather than late. The column fills, and the next item waits in triage instead of being quietly absorbed as one more thing everyone's juggling. That's not a smaller problem (the release date pressure is exactly the same), but it's a visible one, which means it can be talked about Tuesday afternoon instead of discovered Thursday night when three "verified" items turn out not to have been tested properly at all.

The forecast reacting to that queue is what actually changes the conversation with the people setting the release date. "QA's queue is at capacity and growing" said on Tuesday, backed by a number, tends to land differently than the same fact discovered by everyone at once on the day the release was supposed to go out.

Measuring QA fairly, given the work is bursty by nature

QA's output doesn't arrive evenly, so measuring QA the way you'd measure a team with steady, self-directed work is close to guaranteed to produce a misleading picture. A quiet week isn't laziness; it means engineering shipped less that week. A brutal week isn't a sudden burst of effort; it means a freeze landed and the queue had nowhere else to go. Judging either week in isolation gets the story backwards.

ShipSprint doesn't try to smooth that over with a synthetic score. There's no activity tracking or screenshot monitoring pretending to measure how hard someone worked during the slow week or the brutal one, only completed outcomes, and scorecards adjusted for leave so a week spent on approved time off doesn't quietly read as underperformance the following month.

What actually helps QA get measured fairly is upstream, not downstream: the WIP limit and the triage queue make the burstiness itself visible, as a queue length and a forecast, rather than invisible pressure absorbed by working late. A manager looking at "QA's queue hit its limit twice this month, both times right after a freeze" is looking at an honest description of the job, not a verdict on the people doing it.

Being honest about what this isn't

ShipSprint doesn't have a dedicated bug-tracker object with its own schema. There's no separate "bug" entity with a severity dropdown, a reproduction-steps template, and its own workflow distinct from everything else on the board. A bug is a card, moving through the same columns and the same WIP limits as a feature request or a content edit.

That's a real trade-off, and it's worth naming rather than glossing over. What you don't get is a purpose-built bug workflow with fields tuned for defect tracking specifically. What you do get is bugs competing honestly for the same limited slots as everything else, which is, more often than teams admit, exactly the point. A bug tracker that lives apart from the delivery board is very good at making a defect look handled the moment it's logged, and much worse at showing that testing it, fixing it, and re-verifying it are all consuming capacity someone else was counting on for something different.