Scrum is not that easy and different issues may arise. A recurring question I am often asked is “how do I deal with business as usual (BAU) support work during a Sprint in Scrum?”
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.
Problems managing Product backlog items and Scrum Sprints
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?
The approach I recommend is to view a team’s velocity as its capacity to turn the Sprint Backlog into a potentially releasable increment.
Scrum teams and Velocity
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 Scrum team spends 53% of its available time doing support, that is time not available for the Team to develop new functionality. This often indicates a brittle codebase 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 codebase they have no capacity to develop new functionality. Death spiral!
Note – 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!
Agile and the Scrum board
What I recommend for managing BAU work during a Scrum Sprint is to set 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 color of these post-it’s 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 analyzed during the retrospective and the team can decide how to ultimately reduce the burden of support it is carrying.
Agile Practices leading
Bruce Keightley Leads our Agile Practice. He holds an MBA alongside his Certified Scrum Master and Certified Scrum Product Owner certifications and is passionate about business improvement using common sense tools like Scrum.
Bruce served in the Royal New Zealand Air Force for over 23 years as a pilot, flying instructor, staff officer, and commander. On leaving the air force he moved to the Middle East, where he worked as a contract instructor, personnel manager, and project specialist. He returned home after eight years and began consulting work, specializing in management and training. Bruce joined Clarus in 2011 and has been involved in teaching, implementing and coaching Scrum with a growing number of clients.
Bruce’s extensive military career has ingrained the Agile principles of inspect and adapt; this combined with his extensive and practical leadership and management experience has produced an unusual but extremely effective skill set.
Did you hear about The Lean Product Development guru Don Reinertsen? He is another source of amazing Agile and Scrum practices that may help any organization and complex management situation.