Estimating stories is based on the notion that, with time, a team earns experience in resolving them. With it accuracy is improved and velocity can be established to measure a teams speed. A perfect methodology for establishing reliable prognoses for future sprints.
Bugs are a fact of life for a software development company. While I agree that bugs should all be caught during the development of a story, accepting that this cannot be achieved at all times, should be something that every team should plan for. Instead of stubbornly thinking that the process should rule the team, it should be the other way round.
Of course, bug or story, from the business side it does not matter what the team is dealing with. Both can produce an equal amount of value for the product owner.
In our team we have experimented with some techniques for estimating bugs:
- Estimating completely unknown bugs
- Only estimating bugs which were already analyzed
- Allotting time for bug fixing and not estimating bugs, but rank them instead solely based on business value
With 1. we have failed misearably. For most bugs we have found 90% of the time is spent on the bug analysis. After that the bug fix can be estimated in the same way as a story. By planning the bugs into a sprint we made the mistake that the unknown scope impacted story resolution up until the point where almost every sprint we did this way failed.
Based on the 90/10 ratio (analysis to bug fixing) estimation technique option 2. did mean that we had to plan for analysis which was not something that was covered for sprint planning (we had learned from option 1, but had no real solution how to go on with analyzed bugs). The result was that bug analysis was not done since a sprint focused on the planned items instead. The team did not have time to focus on bugs from the backlog. So eventually they did not get done either.
By embracing uncertainty we have now settled on option 3. We have split up the product backlog into a regular story/task part that can be estimated by the team using story points and a bug backlog. In the bug backlog the product owner ranks bugs based on business value and very rough team judgement. The team allows for allotting a chunk of time during a sprint that it can spend on focusing on bugs. The product owner does not know the exact outcome as it was not possible to plan that anyway before. The ratio of bug backlog versus regular backlog can be adjusted for each sprint depending on the current status of each backlog and the importance and business value of the content.
By taking out the uncertainty it did free up the team again. Sprints were not compromised by unknown bugs. By separating bugs into a different backlog both increased team's regular sprint focus and made us finish bugs which contained significant business value as well.
So it depends whether story points are suitable for you. I would try to estimate bugs using story points first. If that fails try my option 3. It has made our (over 30 sprint old) team focus on older bugs again which contain great business value. It has also freed us from trying to deliver something which the team simply cannot estimate. It was embracing the unknown that got us closer to the reality and also made our sprints successful again while delivering a big chunk (based on the bug to story ratio) of business value through bug fixes. The ratio we used recently was 50/50.