1

Should a bug be added in backlog?

Probably with special rules like

  • a business value of 0
  • no complexity evaluation
  • can be urgent or not
  • can be added in current sprint
Improve this question
1
  • 1
    A Bug is a story written by a failed expectation in real life. Its probably better defined and more real than many feature requests that serve as the basis for your other stories.
    – Kain0_0
    Nov 21, 2019 at 0:56

3 Answers 3

Reset to default
8

Yes, a bug should be added to the backlog and tracked just like any other story. I don't think they should follow any special rules though.

a business value of 0

If a bug is important enough to be fixed, then it has non-zero business value.

no complexity evaluation

If you don't estimate the effort required to fix bugs, then you can't plan your sprints effectively and you may end up committing to more work than you can deliver in a sprint.

can be urgent or not

This should just fit into the regular backlog prioritization process.

can be added in current sprint

If your process is flexible enough to accept new bugs in the middle of a sprint, then you should consider extending it to all user stories. In either case, you'll have to push an existing story out of the sprint to make room for the incoming bug/story. This isn't really traditional scrum anymore, but you'll be one step closer to kanban, where there aren't any sprints and you just work on the most important story at any given time.

Improve this answer
1
  • We are always one step closer to Kanban as soon you decide to change the Scrum process ;-). This is also part of scrum process to adapt it to your team. This is done during review. In fact Srcum is just a specification of Kanban... Or a snapshot of a Kanban moment. Thank you for you comments. it make me feel less alone.
    – Bastien Vandamme
    Nov 20, 2019 at 4:43
2

Bugs undermine confidence. Your confidence in the system, the confidence of the company in your job, the confidence of the company in the system and the confidence of the end-user in the company and its service or product. In other words, bugs undermine expectations with doubts.

It might seem they have no "business value", in the strict sense of adding new features or capabilities. They are more like a debt. A debt you have to pay before it's too late. When it comes to debts, time is your enemy. Bugs should be fixed ASAP. Otherwise, we create "expectations" (new capabilities, features, business opportunities, etc) upon false premises (untrustful code).1

I somewhat disagree with @casablanca, who has stated that a bug should be added to the backlog and tracked just like any other story. IMO, bugs should be prioritized and be the first thing to do in the backlog. It's a debt you can not afford not to pay.

Why I do think so? Because of the Normalization of the Deviance, which is present in most of the system with high rates of technical debt.

So yes, they should be added to the backlog and get priority over other milestones of the sprint.

1: worth reading Docs' answer and the link he shared. It's very insightful.

Improve this answer
3
  • "It might seem they have no "business value", in the strict sense of adding new features or capabilities." Not only in the strict sense. This is the definition of giving "business value". And business value is feature that help the business, not these feature nice to have you think are important.
    – Bastien Vandamme
    Nov 22, 2019 at 0:57
  • "bugs should be prioritized and be the first thing to do in the backlog" A bug can be related to UI and in this case, no there is no reason to prioritize it. But yes critical one must be done first and probably be deployed as hot fix before the end of the sprint.
    – Bastien Vandamme
    Nov 22, 2019 at 0:59
  • To my experience, bugs categorization is the way some people find to excuse the normalizarion of deviance. If they are cheap and easy to fix, there should not be excuses to fix them immediately. If they are critical, we agreed, they get prio. In one or another way they must be fixed asap. If your company is oriented to service you will find that no customer sets its DoD and the billing millestones allowing bugs. And it has very little to do with your management methodology. Whether you do agaile or waterfall is irrelevant for the matter.
    – Laiv
    Nov 22, 2019 at 15:58
1

If you can fix a specific bug so soon that you would delete it from the backlog within the, lets say, next ~20 minutes after you had put it in, and you don't have a policy to log all bugs for statistical purposes, it is debatable if it is worth to invest the effort of keeping the bug report by putting it into the backlog. It is not uncommon that certain bugs fall into this category, especially when you have a policy to fix most bugs immediately before writing new code.

But each bug one cannot fix immediately needs to be tracked it somewhere, and the backlog is actually a good place for this. Of course, your team could also decide to use a different place, like a bug database or a separate "bug log", but that is more a matter of personal taste.

See also: the famous Joel Test, points 4 and 5.

Improve this answer

Your Answer

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

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