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
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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.
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.
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.