Unless you’re on one of the few lucky Scrum teams that gets to focus entirely on the development of new software, you need to support your production systems while at the same time moving forward with new functionality and projects. Most in this situation have seen what started out as a very successful Sprint completely destroyed when the demand for production support came calling. In order for your Scrum team to be successful, you’ll need to thoroughly understand how production support fits into Scrum and how it can be managed so as not to reduce the consistency of your velocity. Some tips on gaining better control of the impact production support can have on your velocity include:
- The Scrum Master (SM) and Product Owner (PO) need to monitor requests for production support to ensure it is truly production support and not newly requested functionality that belongs on the backlog for prioritization.
- The SM and PO need to work in tandem to ensure that production support requests are not going directly to the Scrum team for resolution. This will require the SM and PO to reach out to the production system stakeholders letting them know they are the point of contact. Scrum team members should also let those requesting production support know that they need to contact the SM or PO directly.
- Before you can change make any changes, you need to measure the impact that support is having on your team’s availability. The easiest way to do this is to create a user story in each Sprint called “Production Support”. As Scrum team members perform production support they create a new task under this user story and track the activity and most importantly – actual time worked. After a couple of Sprints you’ll start to get an idea of how much production support time is eating into your Sprint and which team members are impacted the most. This tracking provides additional values beyond Scrum including the ability to identify more problematic systems that may need an overhaul to reduce support time as well as identifying if staffing levels are too low to provide production support and new product development.
- Once you have a good sense of how much time on average is required to support your production systems, it’s critical to include this number when calculating an individual’s “buffer” time.
In order for your Scrum team to have any chance of successfully meeting their Sprint objectives, it’s critical that “net capacity” be as accurate as possible and that will require accounting for the number of hours required to support production systems.