Ad hoc changes in the sprint backlog
What would you do in the following situation:
Your team is in the middle of their sprint, then suddenly the Product Owner (the actual client) tells our delegated Product Owner that item X, Y and Z (which wasn’t included in the Sprint) needs to be implemented in the current Sprint.
What would you as scrum master advise the team to do?
Oh, by the way ad hoc changing the priority happens very often here. As Scrum master I’ve told the Product Owner many times that this effects the team, but they simple don’t care. (still in the mind set of we’re the boss so we decided)
Pablo
I think it is between Product owner and development team to decide. Dev team and product owner need to renegotiate the sprint scope/goal.
If it is not part of Sprint Backlog, then it should not be included in the current sprint. The Product Owner can wait for the current sprint to finish and include it as high priority item in the next sprint.
The sprint is 1 Calendar duration and at the start, the product backlog items prioritize by the Product Owner and picked up by Dev team to deliver in the current sprint. So effectively the chances of PO coming up with something new in the middle are highly unlikely, given that it will be just few days that the scope for current sprint has been agreed. In case if this happens, means the current sprint Goal is no more valid and hence PO would need to cancel the sprint. The completed items are then usually accepted by PO and new sprint planning meeting with revised product backlog items and revise sprint goal needs to be initiated. As stated, this is very unlikely and Scrum Master should coche / educate the product owner the implications of this on the overall delivery. As the Product Owner Owner is responsible for maximizing the value of the product and the work of the Development Team, his actions will result in lower value and productivity of the dev team.
If Sprint length is too long for the PO, because the PO always wants to change the content of the Sprint Backlog and can't wait for the next sprint, what do your team think about reducing the sprint lenght ?
> What would you as scrum master advise the team to do?
I'd advise the Development Team to give particular attention to transparency, so that the impact of decisions outwith the team's control are made very clear.
> Oh, by the way ad hoc changing the priority happens very often here. As Scrum master
> I’ve told the Product Owner many times that this effects the team, but they simple don’t
> care. (still in the mind set of we’re the boss so we decided)
Have you tried telling the Product Owner about the affect this has on the Sprint Goal? If he or she doesn't care about that, then there are different problems.
By the way, you have referred to the PO in the plural. Is there actually a Product Owner who makes decisions regarding return on investment...or is product ownership represented by some sort of committee?
There are some very pertinent questions raised by other posters. But one thing I would say is that if you can reduce the sprint length, the likelihood of PO's wanting to break the sprint goal will be reduced. A month is a long time, and reducing the sprint to ten working days will mean that the PO will on average only have to wait a few days before the team can pick up the new work in the very next sprint.
Another thing worth discussing with the team is understanding what amount of their capacity is diverted on average to ad-hoc requests. For example if the average team velocity is 50 points, and say 20 percent of their time is used on Ad-hoc work, they might want to consider reducing their capacity for normal backlog work to 30 points and accepting that 20 points will be used for ad hoc requests.
Finally, if the team are always getting ad-hoc requests, you might want to consider assessing Kanban as a more effective approach.