“I’m often asked ‘How do I deal with business as usual (BAU) support work during a sprint?’” Bruce Keightley explains how he balances the workload...
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!
I recommend managing BAU work during a sprint by setting aside a fixed amount of capacity each sprint for support work and then tracking it in a dedicated ‘swim lane’ on your Scrum board. You can also track the time spent with a burn-up graph. This is a simple way of making the time spent on support visible and maintaining one of Scrum’s most critical facets – transparency. At the daily Scrum, team members record time spent on any BAU work on a Post-it and place it in a support swim lane. The brighter the colour of these Post-its, the better! You can plot this burn-up on the sprint burn-down chart, the two lines together giving a more complete picture of work during the sprint. If the burn-up starts approaching the agreed support threshold, then we approach the Product Owner and ask them to make a decision – either stop doing support work for the rest of the sprint or drop something from the sprint backlog.
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?