Dealing with Bugs in the Product Backlog

22 October 2013

Anurag Prakash
American Express


How do we deal with bugs in Scrum? Do we size them? Do we add them to a separate backlog? Or do we assign them to a different team running Kanban?
Scrum belongs to the family of "lightweight" processes. We need methods that are simple and do not need additional accounting, tracking, or management. Separate teams for bugs may not have the same mental context as the team that produced the functionality. In addition, it's not easy to find people who are really motivated about an exclusive career in bug-fixing. It's cheaper and more efficient to handle bugs in the product backlog itself.

(Note: I will be using "story" and "feature" as synonyms in this article.)

Do Not Size Bugs Found on Unreleased Code

The cleanest approach is to add the bug right back into the current or next sprint, without sizing it. The context is fresh in the team's mind, and so fixing costs will be low. Although this will lower the average velocity, this velocity will more accurately reflect production of bug-free stories.
What about bugs that are found on released code or on items that the current team did not create?
  • Should we just add them to the sprint backlog and not worry about size?
  • Should we treat it as a task and estimate hours?
  • Should we size it in points like a story?
  • Or maybe we should not use Scrum at all and just use Kanban to fix bugs?
If a team is running Scrum and working on stories, not many companies will add another team to fix bugs only, and run in Kanban. Even if there are companies to spare that cash:
  • It may not be efficient for someone other than the story developer to fix bugs.
  • It may not be easy to find engineers who are excited about only fixing bugs (motivation issue).
  • Kanban is better suited to an environment where the work flow is smooth and the team is expert relative to the work items (there is not a lot of back-and-forth experimentation and discussion).

Point-Size the Bugs Found on Released Code

By all means, go ahead. Yes, do it! Bugs are similar to a story in many respects. They can also be considered as a story to implement correct functionality, given the current state of incorrect functionality.

Some Background

To point-size a story, we use a combination of risk, complexity, and effort and come up with a "gut-feel" number. Determining story points is analogous to costing a feature. For example, consider a river that needs two different bridges, A and B, to be built in two different places. Bids are invited for both the projects.
  • Risk: If the geology at A is well documented and it is not at B, then the bid for B will be higher than A, as the risk is higher.
  • Complexity: If geological information for both locations is well documented but the riverbed below A is less stable than it is below B, then A is more complex and so story points/cost will be higher.
  • Effort: Of course, if the location for A calls for more safety and environmental rules, then there will be more procedures and higher effort to carry out the same activities than there will be at B.
Software feature-costing (story-pointing) is similar. Unknown code base can represent a risk, highly complex algorithms are a complexity, and if there are too many items to change, then it's high in effort.
  Story/Subfeature Bug
Risk May arise from a fragile code base, unreliable dependencies, or new libraries being used, etc. May arise from an unknown code base that no one is familiar with. May arise from badly written existing code, etc.
In general, there is more risk in the case of a bug because most of the code touched will be some prior code for which engineers may not have the current context.
Complexity A source of complexity could be algorithms or complex data structures or too many threads that need to be synchronized effectively. Complexity of bugs may arise out of the need to modify a complex code or having too many touch points. There may be cases where it's complex to change the code base.
Effort Depends on how many steps are needed. How many modules, what company procedures. There may be approvals and reviews and compliance requirements. Similar to a story.

How to Assign Story Points to Bugs

Size a bug similar to a story. Use the same guideline of Risk + Complexity + Effort to assign the points.
  • If a bug cannot be estimated immediately, then add a spike. It may be a good idea to always add a spike before you size the bug.
  • The product owner should prioritize the product backlog as usual.
Another opinion is that bugs should not be sized like stories, since bugs have more uncertainty. While that may be true to some extent, the uncertainty can be easily mitigated:
  • Having a spike already mitigates some of the uncertainty.
  • If you are using Fibonacci scale -- 1, 2, 3, 5, 8, 13, 21 for the stories, where 21 is the largest size -- make a rule to limit the bug size to 8 or 13 in a sprint.
Resolving a bug can typically include tracing the code, single-stepping, retesting, analyzing, changing the code. . . .
  • After the initial spike, if the bug is estimated to be larger than 13, then it can be broken down into a Root Cause + Fix story.
  • Root Cause is the investigation phase. It can have acceptance criteria and it can be demo-ed.

So How Do We Tell Marketing How Long It Will Take?

As usual, just use the velocity.
  • Number of sprints = Points in backlog / velocity
  • If marketing is only interested in new features (stories), we can still predict the release by using the percentage of new stories in the backlog.
    • Assuming bugs make up 30 percent of the points in the backlog and overall velocity = 20, then: Number of sprints = Total story points for new features / (70 percent of 20).
Your comments, suggestions, and alternate ideas are all welcome. As true proponents of Agile, we should always be open to new innovation in lightweight processes with low tracking requirements.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Be the first to add a comment...

You must Login or Signup to comment.