Estimating Bugs in Scrum

In this post, I’ll show you how to handle bugs in your Dynamics 365, PowerApps, Power BI or Flow projects when you’re using the Scrum framework.

Mike Cohn, a mountain in the Scrum community recommends estimating bugs. He’s wrong.

Read on to find out why.

Bug Estimators

Bug Estimators treat bugs just like any other product backlog item. When a defect is reported bug estimators write a card for it, estimate the effort to resolve it, add it to their product backlog, and work on it when the product owner ranks it at the top of the product backlog.

The reported advantage of estimating bugs is that you can track how much effort your development team is spending resolving defects. This data can be useful in planning the team’s capacity in the upcoming sprint planning.

For example, the Grasshopper team’s recent average velocity has been 50 story points per sprint. Mikaela, the product owner, has prioritised 20 points of bugs for the upcoming sprint. Team Grasshopper can forecast that they have 30 story points of capacity remaining to work on new user stories.

Scrum trainer and author, Mike Cohn, recommends estimating bugs, Should Story Points Be Assigned to a Bug Fixing Story. But I don’t follow his recommendation of writing user stories for fixing bugs or estimating them. Only a few Scrum teams follow this practice.

What’s the alternative?

Bug Zappers

Bug Zappers treat bugs differently to other backlog items. When a defect is reported bug zappers try and avoid writing a card for it. If it’s a defect affecting a current sprint backlog item, they’ll fix it immediately. If it’s a critical or high-severity defect affecting a feature from a previous increment, they’ll often fix it immediately. If it’s a medium or low priority defect, they’ll fix it if the root cause and solution are obvious. Otherwise they might create a card for medium and low severity defects if there is a realistic chance that they’ll actually fix them one day.

Bug Zappers never estimate bugs. They realise that it’s often impossible to estimate the time it will take to resolve a defect until you’ve analysed the root cause. And it’s impossible to estimate how much time it take to troubleshoot and get to the root cause. It could be 5 minutes, it could take all day. That’s why bug zapping teams don’t waste time estimating bugs.

Sometimes you’ll inherit a business application with a lot of known issues. Or you’ll have accumulated several medium or low priority defects in your backlog. And you want to invest time working on those cards in the next sprint. How do you plan your capacity?

For example, the Ladybird’s team recent average velocity has been 50 story points per sprint. Patricia, the product owner, wants to resolve four medium-severity defects in the upcoming sprint. Team Ladybird reduces their capacity for new user stories from 50 points to 30 points, and brings the four defects into the sprint backlog. It’s an educated guess how much they need to reduce their capacity; Ladybird doesn’t know whether they can actually resolve all four defects in the sprint or not.

Team Ladybird can then either assign some of its developers to fixing the defects while the rest of the team works on user stories. Or the development team can all work on user stories until the stories are all done and then turn their attention to the bugs. Either way, their bug-fixing capacity is fixed and their velocity for delivering valuable story points is diminished.

Scrum trainer and author, Mitch Lacey, recommends zapping bugs, Managing Bugs in Scrum and Agile Projects. I do to. Almost every Scrum trainer, Scrum coach and Scrum team tends to zap bugs.

There are several advantages to bug zapping:

1. Estimating bugs is almost impossible. You probably need to troubleshoot a defect for a while before you know the root cause and can estimate the time to resolution. If it’s a serious defect, that effort is better spent just fixing the defect.

2. Writing cards for bugs is a waste of time. Only write a card for a bug when you really have to.

3. Estimating bugs is dangerous. Teams that estimate defects in story points, tend to include those points in their measure of velocity. But most teams use the velocity not just to forecast future capacity, but as a measure of the team’s productivity and the value the team has delivered. Fixing bugs is not delivering value. The bugs shouldn’t have been there in the first place!

You Should Zap Bugs

If you’re delivering Dynamics 365, PowerApps, Power BI or Flow using Scrum then your team should be zapping bugs as soon as they are detected. Spend as little time as possible triaging them, prioritising them, and writing cards for them. Save that time for fixing them and getting back to more valuable work as quickly as possible. Never estimate defects using story points.

I’m not saying he’s wrong, but I think Mike Cohn is on his own.