Running Sprints With Client-Reported Bugs

Sprints assume you can plan the work in advance. Client bugs assume nothing of the sort — they arrive when a client clicks the wrong thing on a Tuesday afternoon, and they expect a response that week. If you run an agency on a sprint rhythm, that tension is familiar: the plan you set on Monday is half-wrong by Thursday because three "urgent" client bugs jumped the queue.

You can't stop the bugs from arriving. But you can stop them from quietly wrecking every sprint.

Why Client Bugs Break the Sprint Model

Classic agile assumes a backlog you groom and commit to. Maintenance and retainer work doesn't behave that way:

Bugs are interrupt-driven. They don't wait for planning. A site goes down, a form stops sending — that's now, not next sprint.
Urgency is set by the client, not you. Their "critical" might be your "minor," but they're paying the retainer, so it lands mid-sprint regardless.
Volume is unpredictable. A quiet week and a plugin-apocalypse week look completely different, and you can't see which is coming.

Try to run a rigid, fully-committed sprint over that and you'll blow the plan every time — then feel like the process failed, when really the process never fit the work.

Reserve Capacity, Don't Fight the Stream

The agencies that make sprints work for client bugs do one thing differently: they stop pretending bugs are an exception. They plan for them.

Reserve a slice of every sprint for incoming bugs. If history says you get ~20 points of client bugs a fortnight, commit to ~20 points less planned work. The bugs aren't a surprise anymore — they're a line item.
Triage into the sprint, not around it. When a bug arrives, it either fits the reserved capacity or it bumps something out, on purpose. Either way it's a visible decision, not a silent overrun.
Give each client their own cadence. A small retainer client and a big build client don't belong on the same sprint clock. Per-client sprints let each one move at the pace its work actually demands.

The goal isn't a perfect plan. It's an honest one — where the bug load is accounted for instead of pretending it'll be a quiet fortnight.

Velocity Is How You Set Expectations

Once bugs live inside your sprints, something useful happens: you start to know your pace. How much work — planned and unplanned — your team actually clears for a client in a typical sprint.

That number is gold. It's what lets you tell a client "we'll be through the current list in about two sprints" with a straight face, instead of a hopeful guess. And it's only trustworthy if your bugs are sized and sitting in sprints where you can measure them.

How Lantern Helps

Lantern is built for the way agencies actually run sprints — one client at a time, with bugs in the mix.

Sprints scoped per client. Each client gets its own sprint cadence, because a 15-site maintenance book doesn't run on one shared clock. Assign issues to a client's current sprint as they come in.

Bugs and estimates in one place. The same issue your client reported — with its video, context, and estimate — is the thing you drop into a sprint. No re-entering work into a separate planning tool.

Pace per client, measured automatically. As sprints complete, Lantern records how much each client's team actually finished and turns it into a rolling velocity. That feeds straight into a delivery forecast, so "when will this be done?" has a real answer.

The full picture is in the estimation and forecasting guide.

Start your free trial →