Skip to main content

Ad hoc changes in the sprint backlog

Last post 08:03 am April 22, 2014 by Colin Sweetman
6 replies
Anonymous
10:25 am April 10, 2014

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


12:39 pm April 10, 2014

I think it is between Product owner and development team to decide. Dev team and product owner need to renegotiate the sprint scope/goal.


02:47 am April 15, 2014

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.


10:41 am April 15, 2014

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.


10:20 am April 16, 2014

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 ?


03:49 pm April 16, 2014

> 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?


08:03 am April 22, 2014

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.


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.