First, agree on what counts as a bug
Outsourcing teams rarely drown because they have too many bugs. They drown because everyone uses a different definition. A client says “the button color is wrong” and calls it a bug. The developer calls it a change request. A tester logs “sometimes white screen” with no steps and no logs. The developer can only guess.
Write the rule down. If a confirmed requirement does not work as agreed, it is a bug. If the requirement itself changes, it is a change request. If it is polish or a new idea, it goes into the backlog. Put this in the project rules and show it in the client portal. It saves a lot of back-and-forth in chat.
Bug tracking: one list and a 15-minute daily check
Do not let the bug list become a chat history. Every bug needs: title, environment, steps to reproduce, actual result, expected result, severity, owner, status, linked sprint, and whether the client can see it. If steps are missing, send it back. Otherwise developers spend the day guessing.
Set severity by impact, not by who shouts louder:
| Level | Example | Handling |
|---|---|---|
| P0 Blocker | Production login down, core flow broken | Pull people in, same-day decision |
| P1 Major | Main feature errors, workaround exists | Current sprint, fix first |
| P2 Normal | Minor page style issue, wrong copy | Next sprint |
| P3 Suggestion | UX tweak, small copy change | Backlog, review regularly |
Keep the daily stand-up to 15 minutes. Cover three things: new P0/P1 bugs, who is stuck, which bugs will be closed today. Do not read every bug out loud. Once a week, review bugs untouched for two weeks. Schedule them, close them, or turn them into requests. Leaving them open kills trust.
Sprint planning: reserve room for bugs
Many teams fill every sprint with features. Then one production issue blows up the plan. Outsourcing makes this worse: one client call and the schedule is gone.
Reserve about 20% of sprint capacity for bugs and support. Keep the sprint goal simple: what will go live this time. Do not write “fix all bugs.” That is not a goal. Every task needs an owner and a reviewer. “Tested” is not done until the tester signs off.
Do not shove change requests into the current sprint. Tell the client: we can take it, but what comes out? Drop a feature, or move the date by two days? Say this early. It is easier than arguing later. In Stepwise, bugs and sprints sit in the same project view, linked to requirements, tasks, and work hours. The client portal shows only what the client should see, so you stop sending screenshots and long explanations. Private deployment is also useful for finance and government projects.
Retro: look at two things only
Do not turn the retro into a blame meeting. Look at where late tasks got stuck and whether repeated bugs are increasing. Then change one process point and test it next sprint. For example: every bug must include reproduction steps. Run it for two weeks and see if developers get interrupted less.
Tools do not fix a messy process. Agree on the rules first, then use a platform like Stepwise to make them stick. Run two sprints. The messy parts will show up fast.
