This has been asked several times already but none of the answers fully convince me.
We are an R&D team doing some support from time to time. Most of the support work can be included in capacity of the team so that the Focus Factor can be set accordingly.
We have one "batman" that is on support every week and his/her capacity is lowered so that he/she can focus on customer support.
But sometimes "batman" he needs a help from other team member, who is a domain expert and needs to fix some particular issue. If the issue is small then there is no problem but what if the amount of work is substantial?
- Should we create a new sprint task and estimate it and remove some other task from the sprint backlog which has a similar size?
- Should the story points for completing this task be counted as those of the stories that were taken during the planning meeting? In fact we had to remove some item we committed to deliver it so the amount of work done was lower than expected.
- Maybe we should we track the time spent on those instead and try to not remove anything from sprint backlog? In this case we don't have to estimate (which might be incorrect especially for harder bugs), just count time that was spent on fixing particular task. The drawback is that using this approach the velocity will be lower and if this is very unusual situation only some sprints will be affected.
What is more, even if I could accept estimating the support bug and counting its size together with other tasks taken into the sprint during planning (after all this is the product improvement), I am not convinced we should do the same with non-development tasks (broken build system that developer needs to fix, access to bug tracker was broken and some developer needs to take a look). In this case should we track bugs and non-development separately and differently?
It's clear for me that repeating issues tracking is much easier but I am particularly interested in the ones that are not happening that often and have a significant impact on the time the development team can spend on delivering sprint tasks. We had an issue with a system build that took 2 man weeks to solve and it has happened only once; then a big part of the sprint tasks were not delivered in that sprint. How to track such a issues so that our velocity measure will be correct?