Managing Bugs with Scrum

Thursday, October 2, 2008 – 7:30 PM

A lot of bugs. Some might say an infestation!So building on my post from earlier this week – Scrum and Supporting Your Existing Products -and reflecting on an interesting thread I’ve been following here at Microsoft. I thought I’d write a bit about how to handle bugs on your current product development.

“We’re doing Scrum but we have a lot of postponed bugs.”

Heard that one in your team room? A postponed bug is a bug that the team isn’t fixing now but might fix later. As opposed to a bug that’s been marked “Won’t Fix” which means nobody has any intention of fixing it… ever.

Won’t Fix bugs are fine. The Product Owner has ascertained that they’re not important to your users and will not impact their use of your product. These bugs are effectively closed forever. If this changes – because users start to make different demands of your product – then you can open a new bug.

What to do with postponed bugs?

Postponed bugs are ones that everyone knows you have to fix to ship… but nobody wants to do the work right now. Sound familiar? Postponed bugs mean that you can’t really ship. Obviously the solution is to never have any postponed bugs and to fix every bug the moment it’s reported. In practice I feel there needs to be a little bit of latitude here.

  • There should be no such thing as a postponed bug. Bugs either get resolved “Won’t Fix” (ever) or “Fix” (as soon as possible), not postponed for some undetermined period.
  • Bugs that are resolved Fix and impact stories being worked on in the current sprint should be added as tasks to the sprint backlog for the current sprint. Essentially they’re simply indicators of incomplete work. This is the only way to be “done” with the story at the end of the sprint. You are testing stories in the same sprint that you develop them in right?
  • Bugs that are unrelated to the stories in the current sprint go on the product backlog. But, and this is the important bit, you can’t keep pushing them out into future sprints.

So how do you prevent bugs lurking in the product backlog forever? The best way to ensure this is to set a bug cap. Meaning “the product backlog can only have N active bugs in it”. This number N needs to be really quite small. Small enough that the team could fix all of them easily within a few days. This prevents the situation where you’ve built up a bug tail and need several “stabilizing sprints” before you can really ship.

Beware the trap of thinking that you can postpone a lot of low severity bugs and that’s OK. A lot of minor defects in a product start to feel like one big one to users. Imagine buying a new house and every room you look at has something a little bit wrong with the construction. It all adds up. After a while you start thinking “If there’s all this little stuff what big things are lurking that I just haven’t seen yet?”

From experience I’d suggest that you get the team and the Product Owner to agree on this up front, right at the very start of the project. Being a Product Owner is a tough job and there’s always the temptation to try and push off fixing bugs in order to have the team add another shiny new feature that you know users will love. All the while conveniently forgetting about the horrendous bugs in a feature, or features, that shipped months ago.

The bug tax

There’s actually another completely different reason for minimizing the number of active bugs… Tax.

Having a lot of active bugs means that you have to manage them, triage them, track open/closed and fixed rates. All this takes time and effort and adds no value to the product. Imagine if you only had seven bugs to track? Two relating to work in the current sprint, these are being worked on by the team. The remaining five are to be prioritized and worked on in the next sprint. With seven active bugs you don’t need long triage meetings and reports!

The tax of dealing with bugs is greatly reduced and you can spend more time working on features. I worked on a project a while back where we ended up with a large number of bugs kicking around. Eventually things came to a head and we got the number down to something mush more manageable and it was amazing how much time we saved by not having to track these bugs not to mention time spent working with buggy features.

  1. 3 Responses to “Managing Bugs with Scrum”

  2. Your number of N bugs..

    What time of number are you talking about? I have a small team of 2 developers so I would imagine it should be small.

    Also do you ever use a specific BUG sprint? or just allocate the first week to bugs?

    By Patrick on Aug 8, 2011

  3. Hi Patrick,

    I measure bugs in terms of time it would take to fix. Say your team has 20 bugs and the team figures that typically they can fix 3 each per day. That means you are 3-4 days away from being shippable. Depending on your product, your team and the stage in the release cycle that may or may not be OK. For example if you are a web site and you ship every few days this is bad. I never use bug specific sprints, that’s generally a bad sign because it means that your bug backlog has built up to the point where you cannot ship..


    By Ade Miller on Aug 17, 2011

  1. 1 Trackback(s)

  2. Oct 5, 2008: Scrum and Supporting Your Existing Products | #2782 - Agile software development and best practices for building Microsoft .NET applications.

Sorry, comments for this entry are closed at this time.