Should bugs be estimated in story points?

Question

Should bugs be estimated in story points according to the Scrum methodology?

In particular, what if a bug appears to be a quite complicated task, which in fact is a some missed functionality which has to be added, but it is formally still a bug from the client's point of view?

Answer 1

some missed functionality which has to be added

It is not a bug; it is additional functionality.

If the client still wants to classify it as a bug, that's fine. For the team doing the work it is a new effort. Therefore it should be treated as such.

EDIT

As a framework, Scrum does not specify specifics of process. There are no requirements to use user stories, story points, or even bugs. There are some common "best practices" out there. The team must determine what and how to use metrics, processes, etc. to the benefit of the product.

Answer 2

I believe this largely depends on the source of the bug. In my experience bugs are picked up in one of two ways:

1. Bugs in the work which is currently being developed
2. A bug which escaped the in initial QA net and has been either found in a regression test, some exploratory testing, or reported by a customer.

If the bugs you're talking about fall into the first category then they should already be covered in the User Story estimate - how long a piece of work will take to complete includes its estimation of complexity.

However, if we're talking about bugs which have been detected outside the current sprint then there are a couple of different ways of doing this. If they're P1 issues then they're likely to interrupt the current sprint and any estimation is most likely an overhead you don't need (and will be to be looked at immediately regardless of whether they're 1SP or 10SPs). However bugs which can be added to the backlog should be treated as any other backlog item (priorised and estimated alongside any other items). It's also worth mentioning that not all issues raised by customers are bugs, some are scripts/data fixes which should be treated in the same way.

Ultimately any bug will take time time out of your sprint, but a low priority bug which will take a long time to fix will have a much lower business value than an urgent User Story. Estimating the effort involved in fixing it makes this a lot clearer.

In short, estimating bugs for active User Stories and P1 support issues gives little value but there are definite advantages of estimating anything which can be scheduled to be fixed in future sprints.

Answer 3

In my experience, when a bug is first logged (or estimated), it fits into one of two types:

1. Trivial. e.g. "The background should be beige, not maroon."
2. Of unknown complexity.

What my Team does is estimate 0 (or 0.1) points for 1., and for 2. we use the same estimate every time. In our case 0.5, but you should use historical data to determine the average complexity of bugs for your Team.