Stakeholders constantly change the requirements

Why would stakeholders want to interfere with the team’s plan for meeting the Sprint Goal?

Are the team actually agreeing Sprint Goals with the Product Owner, and do stakeholders respect the PO’s ability to negotiate those goals on their behalf?

Are the changes in requirements occurring based on the work being reviewed during the Sprint Review?  If so, then your Development Team is not understanding the purpose of Scrum time-boxing.  That is exactly what you want to happen. 

If the stakeholders are changing their requirements without seeing the work that is being done then again, I say this is what Scrum was designed to do.  However, in this situation all of those requirements changes should be funneled through the Product Owner so that they can be reflected in the Product Backlog. The Development Team should continue their Sprint and deliver the value that they forecast.  UNLESS, the requirements changes make any work done to day obsolete and in that case I would suggest cancelling the Sprint. But that is a very extreme case and should be highly scrutinized before doing so. 

Who ever is getting upset because of the Agile Manifesto statement of "Embracing change over following a plan" are not looking at the principles listed.  There are many that say to embrace changing requirements but there are also many stating the working software is the goal.  The purpose of Scrum's time-boxed Sprints are to allow work to be done, reviewed and requirements adjusted on a specific cadence in order to minimize waste associated to frequent changes. 

Read the section of the Scrum Guide that describes the Product Backlog.  (https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) it explains that the Product Backlog is the source for all requirements and that Product Owner is responsible for ensuring that the requirements are accurate.  It also states the the requirements will constantly change and those changes should be reflected in the Product Backlog. The section on on the Product Owner (https://www.scrumguides.org/scrum-guide.html#team-po) states the Development Team works solely based on the requirements contained within the Product Backlog.  The section on the Sprint Backlog states that only the Development Team can change the contents of the Sprint Backlog. 

There are a lot of opportunities for you as Scrum Master to provide the service of helping the organization understand Scrum among other services listed in the Scrum Guide. 

To answer these questions directly (I added the numbers to help tie answer to question)

In that situation I have a question- 1)to when is the line/moment they can change the requirements?  2)When a US is goinig to sprint? 3)How far you can change the requirements in progress work? 4)Then it’s in sprint but is not In Progress yet? 5)Or in every moment and we are not right?

1) Requirements can change at any time but new/changed requirements should be captured in the Product Backlog and not immediately introduced into a Sprint.

2) User Stories are introduced to a Sprint during Sprint Planning.  But stories can be removed/added to Sprint Backlog at any time based on new information after discussion between the Development Team and the Product Owner. Ultimately the decision up to the Development Team to make.

3) You can change the requirements for in progress work as much as you need based on stakeholder feedback or discovery from the Development Team while implementing. Same answer given to #2 applies to what to do in this case.

4) Again, #2 answer applies here.

5) And one more time, see #2 answer.

Hope this makes sense. I realize that English may not be your first language so if I said something that does not make sense, please ask for clarification and I'll do my best. 

Good luck.

Hi,

Thank you-everything is clear :) And you have right in perfect world. In our situation we have this problem, that no-one from stakeholders listen to the PO nor Dev. Team: "they pay they want and no excuse". They think this is Agile- to change the requirements in every moment event if the US is going to finish. Yes, we canceled in that situation 3 sprints (!!) and it is exhousted.We are  now in that moment, theythe stakeholders made the complaint to our company CTO, that the scrum team is unprofessional. So there is my question: when is this tin red line they cannot cross with changing all over? 

when is this tin red line they cannot cross with changing all over? 

I don't quite understand your question.

But it sounds like there are a few problems here. I have a few suggestions:

• The stakeholders should be going via the Product Owner for requirements.
• Any changes to a user story that's currently in the sprint should be discussed with the Development Team and it's up to the Development Team to decide if it can be accommodated within the sprint. If not, then a new user story can be created for an upcoming sprint.
• Perhaps the user stories are not very well defined, making them unclear at the start of the sprint, which leads the developers to think one way and the stakeholders another.
• The Scrum Master should be educating the stakeholders on the Agile process. It sounds like they have a mistaken belief of "they pay so they get what they want with no excuses"

This is just based on my experience - happy to be advised otherwise from those with more experience!

So there is my question: when is this tin red line they cannot cross with changing all over? 

Are the team actually agreeing Sprint Goals with the Product Owner?