Estimating bugs, spikes and technical debt

User stories are the easy part of estimating. Bugs, spikes and technical debt are harder: the size is often unknown until someone starts, and teams disagree about whether to estimate them at all. Here are the common approaches and when each one works.

Bugs

The hard part of most bugs is finding the cause, not fixing it, so the uncertainty is high.

• Known cause: estimate it like any other story. The team knows what needs to change.
• Unknown cause: don't guess. Timebox the investigation (for example, half a day), then estimate the fix once the cause is known.
• Lots of small bugs: many teams don't estimate them individually. They keep some room in each sprint for bugs instead, based on how much bug work usually comes in.

Whichever you choose, be consistent. If bugs are sometimes pointed and sometimes not, velocity stops being comparable from sprint to sprint.

Spikes

A spike is a short piece of research to answer a question, such as "can this library do what we need?" or "how does the old system calculate this?". Its purpose is to make something else possible to estimate.

• Timebox it instead of estimating it. Agree how long the team is willing to spend, say one or two days, and stop when the time is up.
• Agree the question first. A spike should end with an answer that lets the team estimate the real story.
• Then estimate the story. Once the spike is done, run planning poker on the story it unblocked.

Technical debt

Technical debt is work that makes the code easier to change, such as removing duplication, upgrading a library or adding missing tests. It is real work and takes real time, so estimate it like a story when it is a piece of work of its own.

• Write it as a story. Say what gets better, for example "So that adding a payment type takes days, not weeks".
• Split large clean-ups. A 40-point refactor is hard to plan. Break it into pieces that can each be finished in a sprint.
• Include small tidy-ups in the story. If a story needs some clean-up to be done properly, that is part of the story's estimate.

Cards that help

In EstimateIt, the ? card says "I don't know enough to estimate this", which is often the right answer for a bug or a story that needs a spike. The ∞ card says "this is too big, split it", which suits large technical debt. Neither counts towards the average. Items can be stories, features or epics, and can hold a Jira link, so a bug or spike can sit in the same room as the stories.

Common questions

Should you estimate bugs with story points?

If the cause is known, yes, like any other story. If it isn't, timebox the investigation first. Some teams instead keep room in each sprint for bugs and don't point them.

Do you estimate spikes in planning poker?

Usually not. Agree a timebox for the spike instead, then estimate the story it unblocks once the question is answered.

How do you estimate technical debt?

Write it as a story that says what gets better, split it into pieces that fit in a sprint, and estimate each piece like any other story.

Try it with your team

EstimateIt is free planning poker for agile teams, with nothing to install and no sign-up.

Start a planning poker room