Scrum's great for new development and proactive tasks. But I've never been sure how to use it when the department's obligations also include analyzing/answering/fixing customer support questions, which come in unpredictably, typically have high enough priority to interrupt what we planned on doing, and whose complexity ranges from trivial to major.
The books I've seen so far don't seem to cover that situation.
So how are other folks handling it?
If the development team is the same group that would be handling customer support, the first thing to do would be to adjust the amount of story points that the team brings into the sprint to account for the amount of time doing this. For example, if you were originally basing your story points on a 350 man-hour sprint (5 people over 2 weeks at 35 hours/week dedicated to the project), if you have people required to do customer support work, you may only have 270 man-hours in the sprint remaining. If, under the 350 man-hour sprint you had a velocity of 20 story points per sprint, I'd reduce your planned velocity to closer to 15-16. If a separate entity is handling customer support questions, then you don't need to worry about this as much.
Next, allow the bug reports and enhancement requests from customers to flow into the product backlog. The Product Owner would work with the customer support staff to understand the priority that the external customer is placing on the request and to organize it with the product vision. These stories generated from external entities would be managed just like any other story - they would be ordered by priority, estimated by the development team, and the appropriate number of internally and externally generated stories would be brought into the sprint.
In the event of a critical issue comes during a sprint, the team can take a small period of time to estimate it and work with the Product Owner to determine if it's feasible to address in the current sprint and what would have to be slipped from the current sprint to make it happen or if it would be the first story pulled into the next sprint. The team should consider maintaining sustainable development, product quality, and ensuring customer satisfaction when deciding what to do with a story, negotiating as necessary.
Support and Scrum should not be an issue in a sane, well managed environment.
Ideally, the product should be developed and tested and maintained well enough that bugs are normally caught before they are shipped to customers. Likewise, the small percentage of bugs that do slip through should be documented, prioritised and added to the backlog to become part of the normal scrum process.
However, from time to time, there is bound to be a 'catastrophic' event that cannot be managed that way, and a crisis team is removed from the scrum sprint to address this issue, with the business accepting that scum commitments may slip as a consequence.
What should not happen though, is that there is such a volume of support requests at a high enough urgency that they continually disrupt the scrum sprint. If this occurs, then the solutions may include improving testing and QA before shipping, better training for support to solve more support issues without referring everything to 'software' for an answer, or perhaps as a last resort people with developer skills on the support team to handle these support issues.
Most of the scrum teams where I work have these support obligations. There are a couple different approaches they take to handle them.
One way is to just let it factor into your velocity as interruptions. In other words, you might have a velocity of 20 points per iteration instead of 30 because of your support obligations.
One way is to create a buffer story called "Customer Support" and assign it an appropriate number of points for the amount of support you expect to give that iteration. This method is a little better than the first if the amount of support varies over time. For example, if you do a lot of support right after a major deployment, then expect hardly any for a year.
Some teams separate the initial triage from the actual fixing. We create a separate story for fixing an underlying cause that gets prioritized with the other stories, but finding workarounds and configuration problems gets taken care of immediately.
