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"
- Leaving space for bugs and feature requests
- Leaving space for bugs and bug exchange feature request for stores in sprint backlog
- Still as before must exchange stories in sprint backlog for changes like bugs and feature requests
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.