Today I’d like to share with you a really important aspect of Agile software development – how to account for bugs in your daily plans.
I am frequently asked by teams I consult with how to deal with bugs if you’re Agile and using Scrum. Questions like the following come up time and time again:
“Should I track hours burned fixing bugs?”
“Should the hours burned on fixing bugs count toward my Story Point velocity?”
“When do you schedule bugs and should this be done during Sprint planning?”
You Need to Account For Bugs
My company is often working on many simultaneous projects and having to juggle resources. To get everything done on time and bug free requires careful planning. As a result we have to ensure that we’re considering all aspects of software development including bug fixing. Bottom line is Bugs take time to fix and so you have to account for them. If you don’t, you will have an inaccurate measure of your teams productivity – something that will definitely lead to poor planning and late deliveries. (….read more)
Time to fix bugs therefore, should come out of your teams available capacity. So when one schedules bugs to be fixed, bugs should be estimated just like you do with tasks on the sprint backlog. Developers must therefore determine for each bug scheduled, the hours remaining to complete the bug daily. And this WILL be reflected in the daily burn-down along with tasks.
Calculating the Teams Capacity
Essentially teams have a certain capacity i.e. available time during the week to do meaningful work. This can be calculated as follows:
(# of team members) * (# days in the week) * (hours in the day) = capacity
You should however modify the capacity to reflect reality (time spent in meetings, doing email, vacation etc) so this can get quite complicated. The best thing to do is to figure out what percentage of time per day you get real work out of the team on AVERAGE.
At our company we work on a 4 or 5 hour day therefore:
Actual Capacity = Capacity * 0.5
Once again, don’t get hung up on being extremely accurate as this all averages out in the end. Just be reasonable in your approach. If you want to take vacation into account etc one can get quite fancy about this, but usually a rough estimate works fine. It does for my team.
Resolving Bugs Shouldn’t Count Toward Your Story Point Velocity
The time spent resolving bugs however should NOT be counted towards the Teams overall Story point velocity. i.e. I’m not going to give my team credit for buddy code!
Bugs should be scheduled into a sprint or iteration along with user stories during the Sprint planning meeting. So the total time to implement tasks and fix bugs should not be more than the available capacity you determined for the Team (See above capacity calculation). Note that this total time in hours is the intersection with the Y-axis on your burndown.
I know many coaches will argue that bugs should be tracked seperately and that bugs should be dealt with in the sprint that they’re found. However in practice this is not always practical. Try it, and you’ll improve your teams predictability significantly.
Next week I will give a detailed account of how we do Planning.
If you have any questions about Planning or Bug Tracking in general or if you have strong opinions on this topic, please don’t hesitate to pitch in!