Tips for handling changes in one sprint

I have been working across several development houses. Changes have been forever topics for both SCRUM teams and no-SCRUM  teams. As a SCRUM Master, I have tried to stopped any changes into sprint. But attempts failed and it caused business loss too.Hopefully, my experience will help you guys and in the same time, please post comment if you have any suggestion or think my ideas are shit. So how have I been handling change in one sprint?

First of all, as SCRUM masters and product owners who works in startups and small development house,  we should "expect change" in all manners instead of resisting it as most of customers are very important to business growth.

Now we are expecting change, what we should do next? Should we just let changes in? Of course not,  team can't finish anything if you let all changes into team directly.
1. Let Product Owner know,  change will slow down projects and team productivity will be lower comparing with teams without changes.  But team will expect changes if it impact business values. Some items need to be exchanged from sprint backlog to backlog.
2. Working with team to teach them about proper feeling of urgency in fixing bugs
3. Have a tool and even specific tags/categories to track changes in one sprint
My personal feeling is most of bugs should be fixed straight away if it impacts customer and bugs which don't impact customers can be fixed in 48 hours. And tracking changes in one sprint will help you finding proper

I have found that for small startups, there are often requests of features or changes directly to development team. It must be stopped. And they should send requests to product owner instead of team members.

Now changes come and product owner agree to put that in current sprint for business reason. I have few tricks, you may want to use:

• Ask requestor and product owner standing in front of backlog and move other stories out before move "changes" in
• Ask requestor and product owner send email to business about there are some stories to be postponed because of new "changes"

After two or three sprints, normally I will have a feel how big of "changes" will be with tracking tools (even just with Excel). I have tried three ways after that:

1. Leaving space for bugs and feature requests
2. Leaving space for bugs and bug exchange feature request for stores in sprint backlog
3. Still as before must exchange stories in sprint backlog for changes like bugs and feature requests

For different environment, the outcome are different. 2 & 3 are better than 1 from my personal feeling because with 1, some team may not have enough stories to work with some time because that there is no bugs and much fewer bugs.

 Now, we are here. Will we let every change in? Definitly not. Good product owners will block most of change request doesn't fit product strategy and business value. From my personal experience as project manager, I am intending to block most of changes which are not related with current sprint stories if they are in a big size. How big is big? Every team will have its own definition.

But finally, tracking tools will help you team decide what to do and what to try. Some companies with legacy software and experiences lots of bugs, first important to solve "changes" in one sprint is to increasing test coverage and focus on best engineering practice like code review, pair programming and others. Rewriting part of systems may be good option. Every team will have their own way to handle that because problems are mostly different from one team to another. And team with lots of changes as feature requests, shorting sprint length and splitting stories are good options. And of course. SCRUM Master needs to discuss with team members and product owner to find solution for that.