Start with a Monday morning
It's 9:05. Before standup even starts, three pings in the client group chat: two bugs from last week are "still being looked at," and a third one nobody has picked up. You ask the dev. He says, "I thought that one was a feature request."
That's not a skill problem. That's a broken handoff. Outsourcing teams hit this harder than product teams — more clients, more fragmented requests, harder deadlines. When bugs and sprints are managed in separate worlds, they just eat each other.
Here's what tends to work.
Bugs: one inbox, five states, one owner
One inbox only. WeChat, phone, email, the client's boss messaging a dev directly — if bugs can arrive through five channels, you will lose some. Pick one: everything goes into the same list. Whoever receives it logs it, then replies in the chat with "logged as #123." Five minutes of work that saves thirty minutes of arguing later.
Five states is enough. I've seen boards with a dozen states. Nobody maintains them. Use: New → Confirmed → In progress → Ready for verification → Closed. Add one more, "Not a bug / Deferred," for the "that's not a bug" and "client says no rush" items. Don't delete those — you'll get them again next week.
The reporter closes it, not the developer. This is the most common trap. Dev fixes it locally, marks it done, the client's environment hasn't been updated, it blows up again the next day. Rule: only the person who reported it can close it. The developer can move it to "Ready for verification" and no further.
Four required fields: environment (which client, which deployment), reproduction steps, affected version, expected vs actual. Missing any of them, send it back. Get this right and you cut half the "which browser were you using" back-and-forth.
Set severity levels:
| Level | Criteria | Response |
|---|---|---|
| P0 | Production down, data corrupted | Someone on it within 2 hours |
| P1 | Main flow broken, no workaround | Same day |
| P2 | Bad UX, doesn't block delivery | Current sprint |
| P3 | Suggestions, polish | Scheduled or backlog |
The important part is writing down what P0 means, so the client doesn't treat everything as P0.
Sprints: outsourcing needs slack built in
Product teams can plan at 100% capacity. Outsourcing teams can't. Mid-sprint requests, demo prep, urgent data exports — these will happen. Plan at 100% and you're funding it with overtime. Two sprints of that and people start leaving.
Two-week sprints, plan to 80%. The remaining 20% absorbs insertions and bugs. Insertions aren't forbidden — but if you take one, swap out a task of similar size so the client sees the cost. A lot of PMs are uncomfortable doing this. Skip it and every delay becomes the team's fault.
No sprint entry without acceptance criteria. "Make the report export faster" is not a requirement. How fast? Ten thousand rows in how many seconds? Who decides? If you can't write the acceptance criteria, it's not ready — go clarify first.
Ten-minute standup, three questions: what did you finish, what's today, what's blocking you. The third one matters most. Whoever can unblock it gets named on the spot.
Half-hour retro at sprint end. No documents. Three questions: did we finish what we committed to? If not, why? What one thing do we change next sprint? One thing. Change five and you change nothing.
Connect the two
The biggest disconnect: the sprint plan has no room for bugs, so every bug becomes "extra work."
Fix it by reserving 20–30% of sprint capacity for bugs and tech debt — written into the plan, not done on the sly. Then "we shipped 8 features and fixed 15 bugs this sprint" is a sentence you can actually say out loud, instead of hand-waving about where the hours went.
Also, align releases with sprint boundaries. Don't ship bug fixes as they land. Batch them at sprint end. Your client gets fewer "we pushed an update again" interruptions.
Four numbers worth watching
- Average bug age — new to closed. Over a week means verification is the bottleneck.
- Reopen rate — closed then reopened. High means fix quality or acceptance criteria are weak.
- Sprint commitment rate — below 70% two sprints running means your planning method is off, not that the team is lazy.
- Insertion ratio — above 30%, it's time to renegotiate scheduling rules with the client.
Don't watch these daily. Scan them at sprint end.
Tools make the process stick
A process that lives in a doc nobody opens doesn't exist. What actually helps: the client files a ticket through a portal and it lands in the list automatically; requirements, tasks, and bugs all hang off the same sprint; hours are logged against specific items so month-end doesn't rely on memory.
That's the shape Stepwise takes — requirements, bugs, sprints, and timesheets on one line, plus a client portal so clients file their own tickets and check progress themselves instead of flooding the group chat. It deploys on-prem, so when a client insists their data stays inside their network, you're not rebuilding your toolchain.
If you're still running this on chat groups and spreadsheets, don't change everything at once. Collapse the bug inbox to one, cut states to five, run it for two weeks. Add sprint rules once that holds.
