How to Estimate Bug Fixes for Client Work: Story Points vs Hours

Estimating a feature is hard. Estimating a bug is harder. With a feature, you at least know what you're building. With a bug, you're sizing a problem you haven't fully seen yet — "the checkout is broken" could be a five-minute CSS fix or a two-day payment-gateway rabbit hole, and you often can't tell which until you're already in it.

For an agency, that uncertainty isn't academic. It's the difference between a retainer that holds and one that quietly goes over. So how do you put a number on work you don't fully understand yet?

Story Points or Hours?

Two ways to size work, and agencies argue about them endlessly. The honest answer: it depends on how you bill and plan.

Hours are concrete. If you bill by the hour or run hour-based retainers, estimating in hours keeps your sizing and your invoicing in the same language. The downside: hours invite false precision. "3 hours" sounds exact, but a bug estimate is a guess, and dressing a guess up as a clock reading sets a client expectation you might not hit.

Story points measure size, not time. A point says "this is about as big as the last few 3-point bugs" without committing to a stopwatch. That's freeing — it lets you estimate fast and lets your pace (how many points you clear in a typical week) do the work of turning size into a date. Points work best for teams that plan in sprints and care more about throughput than line-item time.

There's no universally right answer. Pick the one that matches how you already work, and use it consistently — a mix of both across your team makes every estimate meaningless.

Why Bug Estimation Goes Wrong

Three traps catch agencies again and again:

Estimating before reproducing. The single biggest source of bad bug estimates is guessing from the client's description. You can't size what you haven't seen. Reproduce first, even briefly, then estimate.
Forgetting the investigation. Half the cost of a bug is finding the cause, not fixing it. A one-line fix can take three hours to locate. Size the hunt, not just the patch.
Treating every bug as unique. It isn't. The plugin-conflict bug you're sizing today looks a lot like five you've already fixed. Your own history is the best estimate you have.

A Practical Method

You don't need a heavyweight process. You need a repeatable one:

Reproduce, then size. Spend five minutes confirming the bug before you put a number on it. If you genuinely can't reproduce it yet, that uncertainty is the estimate — size it big or split off a "investigate" item first.
Use a coarse scale. A Fibonacci-style scale (1, 2, 3, 5, 8, 13) forces honesty. The gaps between numbers stop you pretending you can tell a 6 from a 7 — you can't.
Anchor to similar past bugs. "This is about as big as that menu bug from last month" is more accurate than a number pulled from the air.
Estimate as you triage. Don't batch estimation into a dreaded weekly ritual. Size each bug when it comes in, while the context is fresh.

How Lantern Helps

Lantern builds estimation into bug triage so it takes seconds, not a separate meeting.

Estimate on the issue, in points or hours. Pick your unit once at the workspace level, set the scale your team uses, and a quick estimate picker appears right on every issue alongside status and priority. Click a size or type your own.

It learns from your history. Haven't sized a bug yet? Lantern fills in a sensible placeholder based on how long similar resolved bugs took for that client — so a half-estimated backlog still produces a useful picture, and the gaps are flagged so you know where a real number would sharpen it.

Estimates feed the forecast, not a spreadsheet. Every estimate rolls up into your team's pace and a delivery forecast per client. Sizing a bug isn't busywork — it's what tells you when the backlog clears and whether the retainer holds.

See how it fits together in the estimation and forecasting guide.

Start your free trial →