Do you have ambiguous user stories in your backlog?
Well, if this is your case you have a powerful tool to fight against it.
Definition of Ready
One of the first things Scrum team has to do is to write a Definition of Ready that allow team members know when user stories will be ready to develop. Every Scrum Master has to help Scrum team to write good Definition of Ready (working agreements and Definition of Done as well).
Product Owner has to write user stories following the INVEST pattern. It means, each user story has to be: Independent, Negotiable, Valuable, Estimate and Tested. Indeed, each user story has to include Acceptance criteria to be validated by Product Owner and the stakeholders.
If Scrum team has to deal with changes in user stories many times during the Sprint the will have to work extra work (most of the time this bad pattern push toward overtime). Imagine you have a User Story that Scrum team estimates as small (or lowest story point) but the Product Owner changes so many times the user story so finally that user story demands a lot of effort to develop so team members should do overtime to develop all the user stories they decided in the Sprint Planning.
What would feel the Scrum team?
Every Scrum team would feel frustrated after working hard only because user stories are not clear or lack of validation from Product Owner (or stakeholders as well).
Indeed, if team members have to deal with ambiguous user stories they have to discuss about it in the Retrospectives including the Product Owner to take action to avoid this bad pattern again and again.
To conclude, Scrum Master has to help the Product Owner in order to write good user stories that respect the INVEST model. If you want to chat about this topic reach me at Twitter (@metlucero), Skype (metlucero) or Email: metlucero [at] gmail [dot] com