How to manage support work in Scrum
This was originally published on the Clarus website.
There is often a great temptation for teams to include a ‘guesstimated’ support work product backlog item into the sprint as some sort of blank container. The argument is that the total velocity of the selected PBI’s now more accurately represents the team’s real capacity.
The problem with this approach is that:
- It is a pure guess as we don’t know how much support work might come in.
- It isn’t transparent. How can the team show how much work is being spent on support when we have a guesstimated placeholder just in case there is some? How can the Product Owner determine if there is value in this support work?
I recommend viewing a team’s velocity as its capacity to turn the sprint backlog into a potentially releasable increment. A key factor in determining this velocity is the amount of time a team spends on BAU support (or fixing reported bugs) – a good indication of overall quality. If a team spends 53 percent of its available time doing support, that’s time not available for the team to develop new functionality. This often indicates a brittle code base and technical debt. As the level of technical debt increases, the team will have less and less time available for new functionality until, ultimately, they are so busy fixing the code base, they have no capacity to develop new functionality. Death spiral!
Remember, if you are in this situation then I recommend you start by measuring this using the ‘Innovation Rate’ metric, which is simply the ratio of time spent building new stuff versus time spent on support versus time spent on expanding (scaling via more servers, higher bandwidth etc). This is a really simple metric to keep as it is simply where the team are spending their time so should be easily available from your timesheet system. If you are genuinely paying down technical debt, you should be decreasing the ‘Maintain’ percentage and increasing the ‘Build New’ percentage. This IS Agility!
But does all support work go into this dedicated support swim lane? Most teams I coach agree that anything less than 30 minutes doesn’t get recorded, anything longer – make a note of it and put it on the board. If an issue is not critical then perhaps it can be captured in a PBI, placed in the backlog and worked on when its priority is high enough. This places control of what should be worked on back with the Product Owner.
So why not make support work visible in this way so that it can be analysed during the retrospective and the team can decide how to ultimately reduce the burden of support it is carrying?