Skip to main content

Stakeholders constantly change the requirements

Last post 02:10 am April 18, 2019 by Ian Mitchell
5 replies
05:15 pm April 15, 2019

Hi, I need your advice. We have problems with our stakeholdests. They change the requirements every sprint and in every User Stories/tasks what are in sprint-almost when it is already at the stage of advanced work on it It is very stressful for development team. PO is on the dev team side and tried to explain the stakeholders, it change ten scope of sprints. They are already angry and claim that we are not Agile, because the Agile Manifesto says Responding to change over following a plan and Welcome-Changing Requirements Even Late In Development. Agile Processes Harnesses Change for Customer Competitive Advantag.

We see, they have no vision of teh product-it’s a reason of this constant changes, but they do not want to hear about it.

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

 

 


07:51 pm April 16, 2019

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?


09:27 pm April 16, 2019

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.


11:13 am April 17, 2019

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? 


10:38 pm April 17, 2019

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!


02:10 am April 18, 2019

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?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.