How to track impediments in SCRUM?

Question

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?

Answer 1

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.

[...]

How to track such a issues so that our velocity measure will be correct?

If you didn't complete any of the work you committed to in the sprint because of this issue then your velocity is correct even if it's zero. That said, if you realised early on that the bug was going to take 2 weeks to complete it might have been sensible to simply close the current sprint, resolve the bug and then started another sprint once this was done (not necessarily including the same issues - you'd need to re-plan the sprint because priorities might have changed). You shouldn't see lower velocity as a 'drawback' but as an indicator of some other problem you encountered along the way.

There's quite a lot of debate about how production support (i.e. ongoing work like 'non-development tasks' and bug fixes) fits in to Scrum. Personally I split it out into a separate activity and assign (as you do) one person to that role (changing them each sprint). We assume a base level productivity drop for that person and chalk it off our expected capacity for each sprint.

My system is based in part on Charle's Bradley's scrum bug handling flowchart and Geoff Watts' explanation of the various approaches to production support in scrum.

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.

On this point, it rather depends how often this happens. If 'not often' means once every 6 months or once every year then I'd be tempted to say that you don't really need to worry about tracking time against these in any great detail - your average velocity will simply drop over the 6-12 month period and you'll get a feel for how much you're actually getting through long-term. If, however, this kind of issues means that you're consistently failing to meet sprint commitments each sprint or, say, every other sprint then that's a more serious problem that probably won't be properly addressed by closer time tracking of the bugs. What you really have there is an issue with how much time you are putting aside for production support or a problem with technical debt or a problem with code quality...

If you need to comply with a reporting requirement within your business then, yes, track the time you spend on bugs/production support and report it in man hour or man days. But I think that needs to be reported in the context of the impact on other activities (product/feature development in particular) in order for to actually mean anything.