A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Problem – When stakeholders disrupt the prioritized feature list of items for a Scrum team

When you start working out some of the basic assumptions of how a Scrum team is supposed to work, one of the base assumptions is that the Product Owner sets the priorities of all the features / User Stories for a Sprint. Now, depending upon business needs, this order can even be changed midway during the Sprint (should be avoided in most cases is what most of the literature says) if there are pressing needs to change the priorities. This can also be done by ending the current Sprint at the point where the decision to change the Sprint Backlog is made, and starting a new Sprint (which can be set to end at the same time as the previous length of the Sprint).
However, this becomes a problem in the case of service teams. Consider a team that prepares some kind of infrastructural work for other teams; in this case, the User Stories are derived from the needs of other teams, but controlled by a Product Manager who decides the priority for the requests coming in from other teams. This can be quite problematic, since other teams all have their own priorities, and the Product Owner can have a difficult time just trying to balance the requirements of the other teams. If the team is lucky, the requirements of the other teams can be somewhat similar, which makes the work of the Product Owner easier.
I have also see a case where the Product Owner had a really tough time, having to fend off a number of pushes from the different stakeholders that impact the work. So, the Product Owner decides the User Stories based on some inputs, and sets the Sprint Backlog for the defined interval. The team starts work.
And then the pressure starts. Another team suddenly finds that their external environment has changed, and decide that they need something fairly quickly from the infrastructure team. The team finds that the external stakeholders are applying additional pressure and the pressure in this case can rise to such an extent that the team is forced to change their User Stories midway during the Sprint. Once in a while, a team can endure this and understand this, but if this pressure and change in Sprint features keeps on happening, the team starts questioning their implementation of Scrum and will suffer reduced morale. However, it is not realistic to assume that the Product Owner can easily overcome the external stakeholder pressure.
I do not have a good solution to this one, and did not have one when the ScrumMaster of the team asked for opinions.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>