What should the Scrum Master do when the Product Owner tries to add more items to the Sprint?

Question

Sprint planning has completed, sprint goals set, all is well. 2 days in the PO asks the lead developer if they could add a new item into the sprint, "it's an easy fix" "another team wants this".

What should the developer and the Scrum Master do? What is the conversation?

Answer 1

The Scrum Master may have a conversation with the Product Owner to understand the workflow on how an item comes into a Sprint backlog. If the Product Owner understands the workflow eg: Create item, Item satisfies "Definition of Ready" (User story template, estimate...), Item lands in Backlog, Item may be pulled in Sprint Backlog if there is free capacity and it does not affect any Sprint Goal.

Answer 2

The Scrum Master can plan ahead for this in multiple ways:

• Plan less story points to the sprints in case this happens again, leaving room to add some extra ad-hocs tickets when they come
• Take out a ticket from the current sprint with the same amount of story points that the ticket the PO is trying to add
• Help the POs reflect and ask them: "what happen if we don't do this ad-hoc right now?" "Adding this ticket to the on going sprint will aid or delay the progress towards the sprint goal?"
• Alternatively, manage expectations by creating a list together with the lead dev and the PO with a set of rules about when it is ok to add a ticket to an on going sprint, so everybody is on the same page

Answer 3

Scrum has always accounted for this situation from the very beginning. The simple answer is that the Sprint Backlog is "locked down" at the start of the Sprint and cannot be changed. This, "Oh, it's just a quick fix." situation was exactly described by Ken in the original book as a prime source of distractions that get in the way of the Team from succeeding.

There's only one recourse, which is a "premature termination of the Sprint". The Sprint ends immediately, nothing is delivered and a new Sprint is started with a new Sprint Backlog and a new end date.

It sounds harsh, but the truth is that the organization won't respect the Team's time unless you say "No" in these situations.

Another aspect to this is that someone early on, I cannot remember who, said the Sprint length should be set to the length of time that the organization go without changing its mind. So if this is a real problem, then shorten up the Sprints.

Back at the beginning, most teams used 4 week Sprints, and this is now seen as way too long. If you can swing it, a 1 week Sprint can be way better. In the example given in the question, 2 days into the Sprint is 3 days away from the end of a 1 week Sprint, and waiting for the next Sprint for the "quick win" is probably going to be fine.

The answer to most Scrum problems is often to make your stuff smaller.

Answer 4

What should the SM do? Well... nothing.

If the SM has coached the team properly, and they understand that they have committed to the Sprint Goal and understand it cannot be endangered, then you can just assume that the person being asked to do the work feels confident that the extra task and the Sprint Goal can be met.

If the extra task is competed and the Sprint Goal is failed, then that's a learning exercise for the Retro - Does everyone in the team understand that the Sprint Goal is a commitment and that it shouldn't be endangered? You could also cover techniques for helping the team handle such situations.

There's nothing wrong with the team doing extra tasks - as long as the Sprint Goal is met. This covers the self-management part of Scrum. The team decide for themselves if they are capable enough to do both activities in the Sprint timebox, and if not, they need to be coached to push back.