"100% utilization" is a bad idea; agile projects rely on adequate slack in the process. "Ideal hours" can be bad too, although some practitioners can make a successful case for them in certain situations. Agile projects are about empirical team capacity rather than making sure individuals are utilized at 100% of some theoretical capacity limit.
Make sure all support work is a visible cost to the project, and apply the same inspect-and-adapt pattern to that work as you do to any other business-driven features. How requires a bit more explanation, though.
Let Capacity Be Your Guide
No invisible work, ever!
— CodeGnome's Law of Transparency
Because the support work isn't free, it must cost the project somewhere. You basically have two choices:
Reduce stories accepted into the Sprint until they fit within your typical velocity range.
This approach treats support work as a drag on capacity, but doesn't attempt to measure it directly. In other words, leave sufficient slack for all the support work and then vigorously protect the team from support work that starts to cut into actual story commitments—unless the Product Owner feels some unplanned support work is important enough to justify early termination of the Sprint or an adjustment to the current Sprint Goal.
Treat support work as a set of user stories with assigned estimates.
This approach treats support work as a visible cost to the project, and forces the organization to make estimates about how much team capacity they expect it to consume in terms of story points, ideal hours, or manpower. These stories should be routinely re-estimated during Sprint Planning, and any mis-estimated support story that consumes too many team resources should be treated the same way as any other user story. Specifically:
- It should be flagged in the daily stand-up.
- It should be escalated to the Product Owner if it puts the Sprint Goal at risk.
- If the Sprint Goal can't be met because of the support story or its impact on other stories, then the Scrum should be terminated early so the Scrum team (along with organizational management) can inspect-and-adapt.
There are valid use cases for both options. In particular, the first option may be necessary when you can't get buy-in from the Product Owner to add support stories or epics to the Product Backlog. Remember, the PO owns the backlog, but only the Development Team can accept stories into a Sprint! Limiting stories to your team's realistic capacity is a good mechanic for making the cost of support visible to the organization.
The second option is the better of the two, though. It conforms more closely to the Law of Transparency, and makes it easier to prioritize support work against other project deliverables. It also allows the project team to treat variance in support requirements as an estimation issue or resource constraint.
Either way, as long as the organization doesn't treat support work as "free" or unreasonably demand that support and project deliverables be treated as first-priorities simultaneously, you will be in a better position to successfully deliver value. Your political mileage may vary, of course.
A final word on the whole issue of support is in order: Scrum isn't anti-support, but it is firmly against allowing unscoped work into a Sprint. Such work is often disruptive to development flow, and can create a great deal of task-switching overhead that can negatively impact team performance. While some of this can be managed through sufficient process slack and prioritization, it easily gets out of hand.
If you can, try to make your support process respectful of the development flow by applying appropriate service-level agreements. Also, make sure your estimates include a sufficient fudge factor for the inevitable task-switching and cognitive dissonance that are caused when support issues interrupt other active tasks.
A single Scrum Team can provide both features and support, but it's a zero-sum game. Both types of work require time, effort, and resources, and the more you spend on one the less you have for the other. If you keep that fact firmly in mind, and ensure that it remains thoroughly transparent to the organization, the pros and cons of the process will generally speak for themselves.