Get certified - Transform your world of work today

Close

Dealing with Bugs in the Product Backlog

22 October 2013

Anurag Prakash
American Express


Introduction

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: 3.8 (11 ratings)

Comments

James Brashears, CSM, 3/2/2015 9:41:34 AM
Great article!
Anonymous, 8/2/2015 5:42:50 PM
I don't agree with the article for many reasons. First, I feel that sizing is something teams ought to avoid, except maybe in general sizes like t-shirt sizes. While I had supported sizing in the past, my experience with it has been that it is generally a wasteful activity. I know the arguments about prediction, planning, etc. How do people know how much to take into a Sprint? The short of it is they fundamentally don't and it is a guessing game at best. The "larger" a feature, the more indeterminable it is. So, we break the story down to better understand it.

One has to wonder how "bugs" (whatever those are defined to be) make it into production. "Bugs" found in released code smell badly and certainly can be unresolved technical debt. Regardless, if "bugs" are making up 30% of a PBL, something is seriously remiss.
Todd Wilson, CSM, 1/25/2016 3:54:20 PM
I'd also like to voice a disagreement with this article and approach. I'd like to point readers to this dissenting opinion: http://www.agileforall.com/2015/10/new-to-agile-build-trust-to-grow-influence-and-impact/

My main point of dissent comes on point-sizing bug fixes on released or legacy code. I don't have a problem with estimating altogether like Anonymous above me. But estimating a legacy bug fix is the Guess of all Guesses, and then forecasting the fix is a lie on top of it.

Quoted from the linked article:

How can you actually determine the size of fixing something which is broken in an unknown way? ... I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it! If those are the only two sizes available to us how can we possibly put them into iterations effectively?
Simon Adams, CSM, 3/14/2016 9:48:28 AM
I'd like to disagree with the article and expand on Todd's answer slightly. I agree you shouldn't take an un-investigated bug into a sprint, because you're committing to something you probably don't understand very well, so its a soft commitment at best. I also don't like splitting bugs into "root cause" and "fix", not least because the overhead of managing that in the backlog can be large. Its also the case that if a bug is root caused, the effort to fix could require a significant implementation effort.

In a sprint we typically assume a % of each engineer's time will be spent on stuff other than their sprint items, for example staff meetings, interviews, preparation for the next sprint planning. During this latter activity the engineers are looking at the items at the top of the backlog and getting ready to go to sprint planning with the ability to make commitments, and if these items include bugs it would involve a root causing effort.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe