I recently experienced exactly the same situation you are describing. While I'm not the Scrum Master for my team, I was the only person on the team who had used any Scrum methods previously. To solve the issue of things coming up and derailing the Sprint plan, we adopted a method we call 'The Batman' which, after some tweaking, has really worked for us.

Every week, one developer is 'The Batman'. They do not complete any Sprint tasks, but are instead made available to do 'whatever work comes up', all of those bug fixes, sudden requests, and "things that must be done now please". While the person who is Batman changes every week, there is always a 'Batman' available for general requests. Our small team rotates through a list, such that each developer spends one week as The Batman, and then two weeks focused on Sprint tasks. We identify the Batman by literally placing a Batman figurine on the desk of the individual filling the role. This makes it very easy for co-workers to correctly identify who is available to help them. Any person may approach the Batman and describe their problem or request. The Batman then makes a decision to either a) identify the task as something non-urgent and place it in the backlog or b) add it to their list and work on it at their next opportunity.

In the (unlikely) event that no such requests exist, The Batman can grab from the backlog for small tasks, or attend to code cleaning/documentation/other things that tend to get neglected. Any tasks the Batman performs still results in a tickets being created in our ticket system, and is 'pulled into Sprint' so that we can track the work, however we assign all 'Batman' tickets a zero story point value. This is because we do not count Batman tasks in our Sprint estimations. We use JIRA for our ticketing system, and while our 'Scope Change' chart shows disappointingly high values, ultimately it does not negatively affect our estimation or sprint planning. By putting a label on 'BatTasks', and assigning them zero story points, it makes it easy to determine what was from the original sprint and what was pulled in by the Batman.

Our Sprints last for two weeks, so in the event that the Batman is a particularly prolific developer, we do not harm the Sprint by making them inaccessible for the entire Sprint. We also found that a solid week of bouncing around handling random quick requests is about as much as we can handle at a time before returning to the comfort and structure of Sprint work. It is also critical that when a Batman's time is up, they must cease work on their Batman tasks and hand over a full description of any incomplete tasks. This goes the same way for a Sprint worker transitioning to Batman - they need to be able to quickly hand off any tasks they were working on. Critical to this is having good documentation on your work as you work, and I think that as a team our in-task documentation skills and ability to hand off tasks quickly to another developer is improving. This is a great skill also for someone who is going on vacation, becomes unexpectedly ill, etc.

Another advantage we found is that *co-workers are now interrupting only one individual, and not side-tracking any developers who are focused on Sprint tasks.* 

We also tried some unsuccessful variants of this approach. We tried having one 'Batman' one day a week (it was not enough) and tried having the entire development team act as 'Batman' one day a week (also not enough). Due to the frequency of requests that came through, we found that always having a 'Batman' on call worked well for our team. What is important is that we gave each attempt a try, and continued to tweak the process to our needs before giving up.

An idea we have considered was also assigning a 'Robin', who would work on Sprint tasks, but if necessary, could be called upon by Batman to help out if the load got to be too great. We have not tried this approach yet, but I like the idea of it.

One interesting side affect of this approach is that the Batman ends up getting exposed to many different aspects of our system. As a team, it has greatly increased everyones general knowledge about the code base, and is helping us all become better acquainted with areas of our code that we did not necessarily have exposure to before.