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?

  • Are you talking about bugs identified with work created in the sprint or issues picked up in live, regression, or exploratory testing?
    – Liath
    Commented Jan 24, 2018 at 15:13
  • About both cases @Liath. They can be considered separately if they are different
    – Andremoniy
    Commented Jan 24, 2018 at 15:18

3 Answers 3


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.


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.

  • I agree with you
    – Andremoniy
    Commented Jan 24, 2018 at 16:17

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.

  • Disagreeing slightly with what I've written above, one value of estimating the scope of a P1 "bug" is to allow you to modify the sprint goal and swap out work.
    – Liath
    Commented Jun 14, 2018 at 16:16

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.

  • My team doesn't estimate bugs at all, and I am curious is that in line with the canonical Scrum practice (in my opinion - no, because it shifts and breaks a proper sprint's velocity estimation)
    – Andremoniy
    Commented Jan 24, 2018 at 14:30
  • @Andremoniy I don't believe there's anything in the Scrum Guide that references estimating (or not) bugs. And why would it skew velocity? Some monster bugs may be estimated too low and some secretly-trivial ones too high, but on average they'd balance each other out - by definition, if you use the average (mean) for their estimate.
    – Sarov
    Commented Jan 24, 2018 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.