How Software Teams Can Actually Manage Bugs and Sprints
Outsourcing projects rarely die from hard technical problems. They die from two things: bugs nobody can describe, and sprints nobody can plan.
Picture the usual scene. A client drops "login's broken again" into the group chat. The PM forwards it to a developer. The developer asks: which environment? which account? what did you click? Three rounds later, half an hour is gone. The fix ships, the client says "that's not what I meant", the developer says "that's what the spec says". Now you're arguing, and the argument usually ends with you doing the work for free.
This is fixable.
One intake, no exceptions
Group chats, phone calls, emails, the client's boss mentioning something in a meeting — none of it counts. Not out of disrespect. If it isn't written down, you can't schedule it, and you can't close a project on it.
Everything goes into one place, and it needs four things:
- Which page or feature
- Steps to reproduce, numbered 1-2-3, not "it just breaks"
- Expected vs actual
- Screenshot or recording, plus environment (account, browser, build number)
Missing any of the four, the ticket goes back. Clients grumble for two weeks, then they get it — because tickets filed this way get fixed faster. Let them file straight into a client portal where they can watch status. That alone kills thirty messages a week.
Bug or change request? Decide before you argue
This is where outsourcing teams bleed money.
Our rule: if it was built per the contract, spec, prototype and acceptance criteria, and the client now says "this doesn't feel right" — that's a change. If it doesn't match the spec, it's a bug.
Changes go through a change order: estimate, quote, sign, then schedule. Bugs go straight into the pool. Put this in the contract appendix and walk through it at kickoff, in front of the client. Don't plan on explaining it later.
Clients rate impact. You rate severity.
Let clients set severity and everything is "critical". Split it:
- Client reports impact: how bad, is there a workaround
- Dev lead sets severity and response time
| Severity | Test | Response |
|---|---|---|
| P0 | Down, bad data, client mid-demo | Now, same-day answer |
| P1 | Main flow broken, no workaround | Within 24h |
| P2 | Workaround exists | This week |
| P3 | Copy, styling, polish | Next release |
Write the reasoning back to the client. If they push back, ask: can this wait a week? Usually it can.
Five statuses, not fifteen
New → Confirmed → In progress → Ready to verify → Closed. Plus two fallbacks: On hold, Won't fix (with a reason and client sign-off).
Too many statuses and nobody maintains them, so your board becomes fiction. Every ticket gets an owner. Unowned tickets rot in three days.
Don't force two-week sprints onto an outsourcing team
One developer spread across three clients can't run textbook Scrum. Stop pretending.
We plan in delivery batches with one fixed weekly planning session:
- Count capacity first. Real available person-days, minus leave, support duty, meetings.
- Plan to 70-80%. Leave 20-30% for bugs and production issues. A team planned at 100% falls apart on the first incident.
- Every client gets at least one "ships this week" item. Otherwise they'll ask for status daily.
- Each batch ends with acceptance — a sign-off, plus short release notes: what changed, what was fixed, what's still open.
Skip acceptance and the project never closes.
Recurring bugs mean missing test cases, not missing people
Fixed the same spot three times? Turn the bug's repro steps into a regression case. Running it before the next change is cheaper than rework.
Three numbers, once a week
- Opened vs closed
- Average time to fix, split by severity
- Reopen rate — if it's high, you're fixing fast but not fixing right
Don't dump these on the client. One line does it: "23 fixed this week, 11 open, zero P0/P1, v1.4.2 is live."
Traps we've stepped in
- Repro steps pasted as a chat screenshot nobody can read three months later
- No release tags, so no one knows which build is in production
- No test time in the batch; "dev tested it" counts as QA
- Tickets not linked to requirements or projects, so timesheets are guesswork
In Stepwise we connect these: requirements and bugs live under the same project, a bug traces back to the requirement it came from, effort is logged per ticket and per person, and the client portal gives your customer one place to file and follow. Enough process to keep things straight, not so much that it fights how you already work. It deploys on your own servers too, which matters when the client wants everything on their intranet.
The short version
Bug management and sprint planning aren't two problems. They're one: tighten the intake, agree who sets severity, protect capacity, then repeat every week. None of it makes a team brilliant overnight. What it does is make delivery predictable — and for an outsourcing shop, predictable beats brilliant.
