The Buglog

Dealing with Legacy Bugs in Scrum

7 October 2013



After writing about sprint backlogs -- how you can create one and why it should be the big elephant in the room -- I remembered that we rarely see people talking about the nasty legacy bugs the Scrum team gets during the sprint and how to fit them inside the sprint.

First, a disclaimer: When I say bugs, I do not mean bugs from the user story (US) currently being implemented by the team. If the bugs you find are related to the US in progress, then these bugs are part of the current work, part of the current sprint scope. So when I say "bugs" in this post, I mean bugs that we have from previous user stories, from legacy code . . . bugs that don't fit the current sprint scope.

Have you ever asked yourself how to fit legacy bugs into a sprint without endangering the commitment? If so, then this post might help you.

Scrum

The Scrum framework has a well-defined rule regarding the injection of "not committed" work: You don't inject.

If you really need to do something not planned, then you abort the sprint and replan. This obviously makes a lot of sense: The team has committed for a certain scope within a fixed period, and if you add stuff but the time is still the same. . . . Well, no can do. Abort and replan a new sprint.

Despite this beautiful simplicity of Scrum, we know that life is sometimes not that easy. If a customer is complaining about a bug, we should handle it -- and fast. So how can we do that without endangering the current sprint commitments, and without aborting the sprint and replanning everything?

Handling bugs in a sprint

The way I've found to handle these bugs was to create what I call the Buglog.

The first step is that both the team and the PO agree that one team member only (or a pair, if you have lots of bugs and need to keep knowledge in same level) will be available to fix bugs during the sprint. Nothing else, just bug fixing. By one person, I mean any person; you don't have to assign one team member in particular. In fact, the team members will assign themselves daily, according to the bugs in the Buglog.

As you break the stories into tasks and build your backlog during sprint planning (in order to find out what can you commit to), you will consider team availability equal to "Team availability minus 1 team member."

Example: If your team has eight people and decides to have one person on bug fixing, then the team availability will be seven people. If you base your commitments on your velocity only, then you should commit to a bit less than your average velocity, because one person will be "out for bug fixing." Consider it as though each day the team had one person off for vacations.

Now that you did your sprint planning and you know which user stories you've committed, it's time to build the Buglog:

buglog2

The Buglog is a second board, placed next to the sprint backlog, having the top 10 most important bugs -- the ones that must be fixed first. (I use top 10 or 5, but it's actually up to your team and PO to decide. If they are all minor and quick to fix, you can list more, but for the sake of simplicity and quick visualization, keep it small -- you can add more at any time!)

Team member assignment to bug fixing

At this point the team has its sprint backlog, with the committed user stories and the buglog with the most important/urgent bugs.

In the same way that the team looks at the sprint backlog and each team member assigns himself to a task (by picking a task that the team has defined as a priority among the current goals), the team also looks at the buglog and checks current priorities. According to those, someone from the team assigns himself to do bug fixing that day.

(In my experience, the self-assignee is normally the person that knows the most about the bug or the area where bug is.)

It is really important to repeat this: Every day the team looks at the list and agrees on who will do bug fixing. Some days the person from the previous day decides to continue doing bug fixing because it makes sense. But the rule is that we all have our share of bug fixing.

We now have most of the team working in the sprint backlog, and we have this special bug-hunter-of-the-day team member fixing bugs. He or she starts with the one on the top of the list and has as the goal to fix as many possible during that day. (You can even propose a contest for the Mightiest Bug Hunter.)

Team synchronization 

The day's bug-fixing team member should also be present in the team daily Scrum. First because the next day he or she will be back to sprint backlog tasks, and second because it's important for the rest of the team to know which important bugs are being fixed.

I've always carried on the daily stand-up as usual, with team members talking about their sprint backlog tasks and impediments and together defining what to do next (team daily planning). The team member doing bug fixing would be the first or the last to speak, discussing bugs fixed and any doubts or help needed to tackle the next bug. We would ask this person to be the first or last one to talk because that way we wouldn't break the flow of conversation around the sprint backlog when the other team members start discussing it. But nevertheless, the Buglog is seen as part of the overall team scope, just with the slight difference of being handled by only one person each day.

Deciding bug priorities

As the list gets smaller, with the bugs moving to the Done column, the PO will decide which are the next most important bugs.

On one of the teams I worked with, every morning the PO received a report from an offshore quality team with all the newly found bugs. In this case the PO would, every morning, look at the current list of "Not yet being fixed bugs" and look at the report received from quality, and decide if there was any new bug more important than those already in the Buglog. If so, then he would reorder the bugs.

Conclusions of my experience

  1. Legacy bugs are fixed.
  2. You can use this Buglog to add small improvements in older stories or deal with technical debt if/when that is your biggest pain point.
  3. POs are happy because they see stories being done and bugs from the past being fixed, all leading to a more stable solution for the customer.
  4. The team is happy because it doesn't feel interrupted from work on user stories, and as a team everyone can still fix those nasty bugs they are worried about.
  5. The ScrumMaster is happy too -- there is less yelling (I'm kidding), less "we need to replan the sprint because if we need to fix all that, we can deliver our US," and a higher feeling of trust between the PO and the team, because this system allows both to do what needs to be done without anyone feeling that unplanned things can't be handled.
For me this proved to be a win-win situation, a trade-off involving the team, the PO, current customers, and future customers.

I hope it helps you as much as it still helps me and my teams.


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: 4.3 (6 ratings)

Comments

Rohit Ratan Mani, CSM, 10/7/2013 7:03:33 AM
I have come across similar scenario but has taken a different approach.
We have a Defect Backlog area where all Legacy Defects are documented. The defects capture the impacted modules/features. So when we are planning the sprint we check on existing defects in the same area and as per availability add it to the sprint.
As these are legacy defects, customers are living with these defects so the question on criticality is not raised. As we keep releasing the User Stories/Features bugs related to them also get resolved.
Catia Oliveira, CSP,CSM,CSPO, 10/7/2013 9:52:53 AM
Hi Rohit :)
thanks for bringing that up ! :) I also tried that and worked very well., I mean, identifying bugs from same area where you will work on next sprint and bring them into sprint goals. The only drawback I saw with this approach was when we had bugs not related with the areas being touched in upcoming sprint.. that's why the Buglog was created :))
Prabhu Missier, CSM, 10/7/2013 9:40:36 PM
I had encountered this situation since the initial versions of my product didn't use Scrum and a huge defect backlog existed. Add to this the field defects which came in and you had a defect count which was hitting the roof. I tried the defect backlog/Buglog approach but this didn't scale well. The fundamental flaw was in the team focusing on multiple things at the same time, not prioritizing and not committing to a common sprint goal. It also meant the PO was not refining the product backlog regularly. So to keep it simple anything coming in or existing which is of value to a customer goes to the top of the product backlog and that's what the team worked on. If anything came in mid sprint we just stuck to the Scrum principle and informed the customer that there we would be getting onto it shortly. Of course we had a great Product Owner who could negotiate. There were a few nasty must fixes in the early days but over time the product quality improved so much that we could stick to our sprint plans since nothing came up that couldn't wait 2 weeks.
Catia Oliveira, CSP,CSM,CSPO, 10/8/2013 3:17:43 AM
Hi Prabhu
It's a good point indeed. I had that problem of focusing at the beginning too (when we inject the bugs in sprint and Product backlog, unfortunately our PO did not have much bandwidth for negotiation). To solve it, the team agreed (incl. PO) that one person from team would not be consider for the Sprint. So we would not commit to US taking in consideration all team member. This way there was always one person available and totally focused on fixing bugs everyday. To make it more efficient and less boring that person would rotate daily or whenever made more sense (if one bug was too big to be fixed in one day then the same person would want to keep on working on it the next day).

But again, if you have a PO who's able to negotiate then you may as well just pick up bugs in sprint planning and then tackle them in sprint. That is also our preferred way, but unfortunately not always possible.
Prabhu Missier, CSM, 10/8/2013 9:48:37 AM
Hi Catia,

I agree that you have to tailor to suit reality. Your solution is indeed innovative. Just makes me wonder whether not having the whole team committed to the Sprint goal is a sign that Scrum has not been able to solve your problems.

Also I know you spoke about taking the Buglog approach to resolve legacy bugs but having a dedicated bug solver role and bug backlog might sub-consciously induce the team to introduce new bugs as well.
I guess you must be having some metrics about the new defects being introduced. Do these get resolved in the same sprint or do they get pushed to the Buglog?
Mirko Kleiner, CSM,CSPO, 10/13/2013 5:21:32 AM
hi catia

I see your point. May I share with you our solution.

1. dont make a difference between bugs and stories
e.g. a bug in checkout process of an ecommerce application could be much more important than any new story. so do priorization of bugs according business value as you do with other items.

2. estimation is problem
in my opinion main thing to solve is unsure resolution time of a bugfix. we usually estimate those similar as any other backlog item. however to be on the save side we put additionaly buffer to sprint backlog. therefor compare pattern interuppted buffer, that we always use not just for unexpectable issues, but also for managing time of findings
https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus

cheers mirko
David Lowe, CSP,CSM, 10/26/2013 4:28:50 PM
I'm with Prabhu and Mirko in that (1) it could encourage the team to relax on code quality if they know that bugs get fixed later AND may not have to be fixed by them; (2) separating bugs and stories complicates matters (using Kanban as we do, these could certainly be tracked as a different type of story, but I'd worry about having 2 separate boards); (3) one is usually better off building them into a future sprint (unless it is a truly urgent bug that's causing a catastrophic failure (in which case, how the hell did it get into production?!).
Victor Ling, CSM,CSPO, 11/20/2013 4:25:28 PM
We have six agile teams in our development group and five are using Scrum sprint and one is using Kanban. The team that is using Kanban is our designated product support team and manages the "bugs" (defects) and small product change requests. We have tried variations in our Agile practice and found that Kanban is the best practice for managing a continuous flow of defect (bug) correction. We have tried adding defects to our Scrum sprint team backlogs; but we found it can be an Agile anti-pattern to mix new development and legacy defect fixes.
Kwaku Ampomah, CSPO, 11/21/2013 11:28:00 AM
Catia and Victor - very useful info - maybe a version of both approaches could be useful for my teams - hmmmm (thinking cap on)
Pedro Antonio Camacho, CSM, 11/22/2013 2:09:56 PM
I have a problem with this solution, first the term legacy, is it from a previous release from this team or is it from days of lore. The reason I ask is if the bug is from the team we need to fix period. Prioritization has usually been done by severity where severity 1 and severity 2 bugs need to be fixed asap and severity 3 and severity 4 bugs get fixed as we can. We have very well defined definitions for severity 1,2,3,4 bugs. The test team usually holds prioritization meetings where again we use severity levels to drive that.

You must Login or Signup to comment.