Start with one thing: where bugs come in
In outsourcing projects bugs arrive from five places at once — a client shouting in a chat group, a phone call, QA's spreadsheet, email, and production alerts. Three days later the PM asks "did we fix that thing last week?" and nobody can answer.
There's one rule worth enforcing: one intake channel. Clients file through the client portal, QA files in the tracker, internal folks file too. Anything shouted in a chat group gets converted into a ticket by the PM, who replies "logged as #1234."
Don't skimp on fields:
- Which client, which environment (prod/test), which version
- Reproduction steps, written as 1, 2, 3
- Expected result vs actual result
- Screenshot or screen recording
- Blast radius: one client or all of them
Reproduction steps are the highest-value field. A ticket that just says "page errors out" costs a developer a full day of back-and-forth.
Triage: don't let the client assign P0
The most common fight in outsourcing is priority — to the client, everything is P0. Fix it at kickoff by writing the rules into the contract appendix.
| Level | Criteria | Response | Handling |
|---|---|---|---|
| P0 | Prod down, data corruption, money involved | Respond within 30 min | Drop everything, ship a fix the same day |
| P1 | Main flow blocked, workaround exists | Respond same day | Into the current sprint, fixed within 3 working days |
| P2 | Feature deviates, main flow fine | Acknowledge in 1 working day | Next sprint |
| P3 | UX, copy, suggestions | Review at planning | Batch them |
The key point: severity is assigned by the PM and tech lead, not the client. But show the client what a P0 costs — "if this goes in, the two features we planned this week slip." Once that's visible, most clients re-rank on their own.
Sprints: leave room for production issues
Two-week sprints, capacity in person-days, not vibes. Three people for two weeks is 60 person-days gross; after meetings, code review, and integration that's roughly 70%, so about 42 usable.
Then the step most teams skip: carve 20% off the top — around 8 person-days — for production issues. Plan the rest.
Skip this and week one gets shredded by client problems. The board becomes decoration, and the team learns that plans don't mean anything. With the buffer, sprints land on time as long as issues stay under it. If they don't, that's a signal — either quality is slipping or the scope was never realistic.
If you run several clients in parallel, split the board into swimlanes. Everyone can see whose work is stuck.
Keep standups short
15 minutes, standing, three questions: what shipped yesterday, what's next today, what's blocked. Assign blockers on the spot and clear them the same day.
No solution debates, no blame, no percentage updates. Take details offline.
Columns: To confirm / Ready / In progress / Ready for QA / In QA / Ready for acceptance / Live. Cap WIP per column. If QA has 20 tickets piled up, the bottleneck is QA — adding developers won't help.
Close-out and retro
Before every release: test entry checklist, regression scope, release checklist, client acceptance sign-off. Miss one and you'll argue about it later.
In the retro, look at four numbers only:
- Bugs opened, closed, and left over this sprint
- Production issues (P0 + P1)
- Rework hours as a share of total
- Committed vs delivered
The open-bug trend is the most honest metric you have. If it climbs every sprint, the team is chasing features at the expense of quality, and it will blow up within a quarter.
Traps worth naming
- Clients going straight to developers. Work becomes invisible and devs get interrupted. Agree that everything becomes a ticket, and devs only work from tickets.
- Not tracking fix hours. You find out at project close that you lost money, with no idea where. Log bug hours separately so the next quote includes them.
- Silent mid-sprint scope changes. Later the client says "we agreed on that weeks ago." Log every insertion and the schedule impact.
- Fixing without preventing. Five P1s in one module in a week isn't a fixing problem. Check test coverage or whether the requirement was vague to begin with.
On tooling
You can run all of this on spreadsheets and chat groups — until you hit three clients, and then it falls apart. That's the scenario we built Stepwise for: clients file in the portal, tickets attach to the requirement and sprint they belong to, dev and QA move them across one board, and hours roll up by person and project. For private-deployment customers, nothing leaves their own servers.
Don't roll out everything at once. Do three things first — one intake channel, agreed severity rules, and a sprint buffer — and you'll see the difference inside two weeks.
