I'm working in a Scrum project writing firmware code in C for an ASIC.
Every so often we have really hard to find bugs. But how do I time estimate these bugs?
I always tell the Scrum master I do not have the competence to estimate them because I really hate time-estimation of bugs.
How do you guys handle this in your Scrum projects?
How about estimating them based on the average time spent fixing earlier bugs?
Estimate them in weeks instead of hours.
If your Scrum-master doesn't understand the problem with time-estimating a bug-fix, your project would probably benefit from having a Scrum-master with at least minor programming knowledge.
"It's hard to make predictions - especially about the future."
Unless you have analyzed a bug and stetched a solution it cannot be estimated. This is like doing a scrum planning meeting without knowing the backlog.
You can use large estimates to communicate uncertainty. Historic data has some limited value. It does not help a lot for the one bug at hand even when the effort distribution is the same for new bugs. Additionally, new bugs can be easier or harder on average.
You should be abel to build a history of how many story points you can complete in a week, based on consistent story point estimation. This will also include bug fixing time.
For example we know we can complete 20 story points in a week, from previous sprints. The development of those 20 points may be complete within 2 days, however then there is testing and bug fixing. We don't estimate on dev bugs, as each new story should have an estimate that will approximately include bug fixing time. Live bugs should be investigated before estimation, then it should be possibel to estimate accurately.
I asked Jeff Sutherland this, and he told me that at PatientKeeper they have a fixed estimate of half a day to fix a bug. If the nature of your bugs is that they can be rather predictable such that you can find an approximate average I guess this is a fair strategy.
However, in practice I don't find this always to work out. It is often difficult to understand what the bug is, and it might take longer time analyzing it than to solve it. This often makes bugs highly unpredictable and difficult to estimate. All tasks you include in your sprint must be analyzed, and bugs will often require more analyzis than other tasks.
What we've done in such cases of "unpredictable" bugs is to allocate fixed time for figuring out what the problem is. E.g. we choose to spend one day (or x points) on digging into the bug trying to understand it, and then plan to address the actual fix for the next sprint. However, if that isn't sufficient time to figure it out we don't want to waste more time on it in the current sprint, and will have to reconsider it for the next. In some cases the bug might be highly critical, and you just gotta live with an uncertain estimate..
Estimating bugs is a really hard thing. If you can do it, then you likely already have the solution and it's not really a bug anymore :) So, instead of trying to estimate them one by one, my preferred option is to allocate some "bug fixing time" during the Sprint and to fix most important bugs during that time. This is a best effort strategy, you just fix as much of them as possible during the allocated time.
We can classify bug in "I know where it is going wrong I need to update it", "I know this bug is related to this module and any debugging some of these files I can resolve it", "I am not sure why this bug has come up". We can estimate in first 2 cases based on our experience on that project. But estimating for last case is real tough.
One approach that has worked for me is not to have bugs in the first place :)
The way this works is that when a bug is found, fixing it takes priority over story implementation. New features can only be added once the already existing functionality works 100%.
Of course we classify bugs. This stop-the-production-line approach is only applied to critical bugs. Less than critical bugs get treated as feature enhancement stories, estimated and planned in upcoming sprints as any other stories.
Time allocation for critical bug fixing eventually gets reflected in your team velocity.
We estimate for every bug a analyze time of 4h. Also we have a prioritization of bugs. Bugs which are blockers or critical must fixed before anything other is implemented. Many bugs to fix results in lower implemented stories. But we have so a robust software for the next features.
I find that there really is not that much use in trying to estimate bugs. Just prevent them, find them, make them visible (on your taskboard or whatever you use), prioritize them and fix them. The time you spend will impact the velocity. And it's the velocity that matters. It's the velocity that's the indicator on how much progress you can expect in the next sprint(s).
If you are interested in some metrics, use number of bugs per sprint instead.
I asked a similar kind of question some time earlier and got some good responses.
The real goal is to mitigate the risks associated with bugs; i.e. not letting the schedule be effected. Very often, the team will be able to identify which stories are likely to create the tricky bugs ahead of time. So one mitigation strategy is to tackle those stories first, giving the team as much time as possible to cope with the unexpected.
I have heard bug fixing compared to fishing. How long will it take you to fix a mysterious bug? How long will it take to catch a fish? You might try explaining it to your product owner in those terms.
Hi all, you might also consider to allocate a "contingent" for bug fixing during the Sprint (10-20% of the committable time) than use a Kanban way to work them out. That means you can talk with the Product Owner and explain him that the bug fixing costs are under control (as the contingent is your timebox) that empirically will be adjusted at every new iteration based on what the team feels the quality of the Product will be. The Goal is of course to reduce the time and promote transparency. The Product Owner can help in prioritizing a Bug Backlog putting on top the most valuable bugs - normally Retainment value - so that the highest prioritized will be probably fixed... the higher the better.
Working with KanBan, means that the Team sits and look at regular interval (after the daily stand-up is a good time) what is in the Bug queue, uses the expertise of all the team members to figure out where look and what to check, than someone (normally pairing is really good) takes the bug. When the contingent is over the Team raises the hand and talks with the Product Owner, he will have to decide if there are still bugs that have to be fixed - at the cost of a story or more - or they can wait the next Sprint.
In general transparency should enable the Scrum Team (includes PO and SM) to figure out what the cost of fixes is and figure out what to do to balance quality and speed of delivery. It is normally a good way to establish a dialog with PO :-)