In the early days of experiencing SCRUM we used to be in a dilemma about whether or not to size bugs. It was an old piece of software with a lot of history and therefore a lot of technical debt.
The backlog contained a mixture of new user stories and bugs. In the beginning we were assessing the bugs and assigning story points to them. This felt really “agile” and so we continued like that for some time.
However, the unpredictable nature of bug fixing really became a problem. During the sprint, a new high priority bug would come in and we didn’t know quite how to handle it. Cancel the sprint? Break the principle of respecting the team’s commitment for that sprint? How “big” is the bug? etc.
A year later and the team is very adept at working according to Agile principles and this is how we handle bugs:-
Remember that a team’s velocity represents it’s capacity to implement change (new features). Bugs are NOT sized. The team works in a mixture of SCRUM and Kanban depending on the business priority. If the business needs 100% focus on bug fixing then the team falls into a Kanban mode – picking bugs off the queue as they come in (we still maintain a 2 week sprint heartbeat). If the focus switches to new requirements then it’s in SCRUM mode – user story sizing and velocity based planning. Most of the time it’s a blend of new features and bug fixing. And the team’s velocity, over time, naturally reflects that.
At the end of the day, at least you have a velocity that reflects what the team is capable of in terms of implementing new features. Which is what the management need for road-mapping and planning.