It's the same as @JillSanderson answer. But, in my opinion, it's better to use focus-factor instead of reducing capacity. It gives absolutely the same effect (reduced velocity), but it's more logical.

It's almost the same as @WBW answer. Gather all needed information during Sprints, analyze it during retrospectives, find root of problems and try to eliminate it. Maybe you should increase quality of code with special engineering practices (or improve testing) to not spend such a lot of time on bug fixing. Or, maybe you should delegate some work to another team. Or improve planning for reducing the amount of unexpected features from the customer. Or something else. It is hard to give concrete advice, because it depends on many factors. It's your job as Team Lead to find and fix these problems.

It's a "The Batman" answer, provided by @Aurora.

It's the same as @JillSanderson answer. But, in my opinion, it's better to use focus-factor instead of reducing capacity. It gives absolutely the same effect (reduced velocity), but it's more logical.

It's almost the same as @WBW answer. Gather all needed information during Sprints, analyze it during retrospectives, find root of problems and try to eliminate it. Maybe you should increase quality of code with special engineering practices (or improve testing) to not spend such a lot of time on bug fixing. Or, maybe you should delegate some work to another team. Or improve planning for reducing the amount of unexpected features from the customer. Or something else. It is hard to give concrete advice, because it depends on many factors. It's your job as Team Lead to find and fix these problems.

It's a "The Batman" answer, provided by @Aurora.

Although, almost all ways to solve your problem were already described, I decided to write my answer to to add a little bit organization and references.

It's the same as @JillSanderson answer. But, in my opinion, it's better to use focus-factor instead of reducing capacity. It give absolutely the same effect (reduced velocity), but it's more logical.

This approach have one limitation. Focus factor (amount of "external" tasks) should be approximately the same. Otherwise, forecast tasks for Sprint becomes meaningless.

It's almost the same as @WBW answer. Gather all needed information during Sprints, analyze it during retrospectives, find root of problems and try to eliminate it. Maybe you should increase quality of code with special engineering practice (or improve testing) to not spend such a lot of time on bug fixing. Or, maybe you should delegate some work to another team. Or improve planning for reducing amount of unexpected features from customer. Or something else. It hard to give concrete advice, because it's depends from many factors. It's your job as Team Lead to find and fix these problems.

The main limitation of this approach is that eliminating roots of some problems is not always possible. It's all good in theory, but in real world we often have no enough power to fix all things.

Well, it's true, that Product Owner and (especially) Scrum Master should be a "shield" of the Development Team.

Limitation of this approach is obvious. As I had been told before, Scrum Master may have no enough authority to protect well Development Team from unexpected on-demand tasks. On the other hand, business is much more important for Product Owner then Scrum rules.

Good solution with two limitation. 1) Amount of unavoidable tasks should be not to big for "Batman". 2) Developer Team should have more then 3 members, otherwise сapacity (in percentage) will decrease greatly.

In any case, the presence of extraneous tasks in Sprint contradicts to Scrum. It will be ScrumBut (not pure Scrum).

• Extreme programming. According to this methodology, customer may change tasks during iteration without any limitation (honestly, there is one limitation: in case if customer will add new task to current iteration, he should remove task (or tasks) with same volume).

Trick is that cost of changes have fixed cost in Extreme programming. This methodology prescribes a lot of techniques how to ensure this. One times I tried to implement this methodology, but it was too extreme for us :-)

• Kanban. This methodology has no iterations at all. When your WIP has a free space, you can take another task immediately. If you have no need in iterations, this methodology may be best choice for you.

Although, almost all the ways to solve your problem were already described, I have decided to write my answer to add a little bit of organization and references.

It's the same as @JillSanderson answer. But, in my opinion, it's better to use focus-factor instead of reducing capacity. It gives absolutely the same effect (reduced velocity), but it's more logical.

This approach has one limitation. The focus factor (amount of "external" tasks) should be approximately the same. Otherwise, the forecast of the number tasks in Sprint becomes meaningless.

It's almost the same as @WBW answer. Gather all needed information during Sprints, analyze it during retrospectives, find root of problems and try to eliminate it. Maybe you should increase quality of code with special engineering practices (or improve testing) to not spend such a lot of time on bug fixing. Or, maybe you should delegate some work to another team. Or improve planning for reducing the amount of unexpected features from the customer. Or something else. It is hard to give concrete advice, because it depends on many factors. It's your job as Team Lead to find and fix these problems.

The main limitation of this approach is that eliminating the roots of some problems is not always possible. It's all good in theory, but in the real world we often don't have enough power to fix all things.

Well, it's true, that the Product Owner and (especially) the Scrum Master should be a "shield" for the Development Team.

The limitation of this approach is obvious. As I have been told before, the Scrum Master may not have enough authority to protect the Development Team well from unexpected on-demand tasks. On the other hand, requirements from business always is much more important for the Product Owner than the Scrum rules.

Good solution with two limitations. 1) The Amount of unavoidable tasks should be not to big for "Batman". 2) The Developer Team should have more than 3 members, otherwise the сapacity (in percentage) will decrease greatly.

In any case, the presence of extraneous tasks in Sprint contradicts Scrum. It will be ScrumBut (not pure Scrum).

• Extreme programming. According to this methodology, the customer may change tasks during iteration without any limitation (honestly, there is one limitation: in case the customer wants to add a new task to the current iteration, he should remove a task (or tasks) with the same volume).

The trick is that the cost of changes have a fixed cost in Extreme programming. This methodology prescribes a lot of techniques about how to ensure this. One time I tried to implement this methodology, but it was too extreme for us :-)

• Kanban. This methodology has no iterations at all. When your WIP (Work In Progress) has a free space, you can take another task immediately. If you have no need in iterations, this methodology may be best the choice for you.