Can sprint backlog change while sprint is running?

Question

We work on offshore-onsite model and have two scrum masters. Debate started between both SM's with swapping item in the sprint when the sprint is running. Our product owner identified a new critical item and was ready to remove equivalent item from active sprint.

But, we have another problem, if we look at the guide which says "No changes are made that would affect the Sprint Goal" .. We don't have a explicit called out sprint goal as we work on multiple features. For e.g. our next sprint backlog may look something like StoryX, StoryY, StoryZ, StoryXX etc which are all independent and has no relation and can be completed within a sprint by developer. Just to put an example:

Story 1 : Block users from using wildcard in Patient Search .

Story 2 : Implement pagination for User Search .

Story 3 : (Tech. Story) .Net Framework upgdate from 3.5 to latest.

Now my first question is, what should be my sprint goal in this case? I assume the corresponding work associated cannot be changed. Is that right? Is my complete sprint backlog my sprint goal?

My last question, which SM is right? Can we change the sprint goal or not?

Answer 1

This seems to be a good discussion about the usefulness of the Sprint Goal. Let's see... why do you need the Sprint goal in the first place?

First, the Sprint goal is meant to provide a roadmap, to the Development team and the PO. It helps to provide guidance as to why the team is building the increment, helps set priorities and offers flexibility when the team realizes that they have no time for implementing a feature. So, if the goal is specific e.g., "Create user registration", then it can be accomplished, even when the scope changes, and "Restore password" is removed from the sprint. Because the goal also supports the Product Owner in creating the product roadmap, it's really useful to work with specific sprint goals.

The Sprint Goal lays the ground for teamwork; it explains why team members need to work together as one instead of pursuing separate initiatives. (From Six Reasons Why You Need to Pay More Attention to the Sprint Goal)

In your case there is no specific sprint goal, so you seem to rely on the negotiation between the Product Owner and the Development Team. Remember, the sprint backlog is owned by the Development Team.

What's important to realize is if and why you need spring goals. There's no good or bad decision making but finding what works best for you.

Answer 2

You have a Product Backlog that has User Stories. The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal.

According to the Scrum Guide

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.

The Sprint Goal is an objective set by the Scrum Team during Sprint Planning and is set after the forecast of the items to deliver.

In the case you mention to try and understand the Sprint Goal, the best we could do is to estimate what could be a good goal but for that we would need performance metrics from your Development Team too for precision.

About changing the Sprint Goal, ideally you will have the sprint without interruptions. With interruptions i mean customers wanting urgent new functionalities or users finding big problems, for instances. That's not what we see often. For that, when setting a Sprint Goal, to be realistic, i suggest you don't think the Development Team will be 100% focused in the User Stories they currently have because that can lead to changes in the Sprint Goal. It's not advisable, but they can happen.

Answer 3

Can you change the sprint backlog during a sprint? Can you change the sprint goal?

The answer to both questions is yes, but you have to appreciate the implications of such changes.

For example, changing the sprint backlog may:

• Invalidate some or all of your planning
• Disrupt the team
• Result in efficiency loss due to context switching
• Set a dangerous precedent where changes to the sprint become the new normal

I would expect the conversation between the Product Owner and the team to go something like this:

Product Owner: I need to bring a critical item into this sprint.

Team: OK, understood. This is the impact this change will have...[explains impact]

Product Owner: Having considered the impact I still believe it is worth making the change. Do we need to consider cancelling the sprint and re-planning? Or will we be able to go ahead with the sprint with this change included?

Whatever the decision that is taken, it would be worth the team discussing this in their next retrospective. Is there a way to avoid this kind of disruption in the future? Does the team need to get better at introducing last minute critical work?

Answer 4

The reasons why it's advisable not to change the goal of a sprint during a sprint are to allow the team the best chance to deliver the product increment, to help maintain a sustainable velocity and to maintain confidence in the regular cadence of delivery. Ultimately I suggest the PO should take the decision on whether to change the scope during the sprint. The PO should listen to the team if they have any concerns, understand that there may have to be compromises made but if the PO accepts that and is willing to justify the decision to stakeholders then I think that has to be his or her call.

You should examine why this has happened. It could just be that mistakes were made during prioritisation but in some cases it could also mean that sprints are too long, making it harder to anticipate what might arise before the end of each iteration.

Answer 5

What you are doing here is not Scrum as Scrum is defined. Some of the deviations include multiple Scrum Masters and a lack of a Sprint Goal. This makes it difficult to give an answer in the context of Scrum.

Now, with that out of the way, you are asking four distinct questions, but they are all closely related:

• What is my Sprint Goal?
• How is my Sprint Goal related to my Sprint Backlog?
• Can we change the Sprint Backlog?
• Can we change the Sprint Goal?

Your Sprint Goal should be established at Sprint Planning. The purpose of the Sprint Goal is to give the Development Team focus to ensure that the outcome of the Sprint - the potentially releasable Done Increment - is something that is useful and valuable to the stakeholders. Throughout Sprint Planning, the goal helps to drive the selection of appropriate Product Backlog Items for the Sprint, with the past performance and forecast capacity helping to drive the number of Product Backlog Items. The goal is a negotiation between the Product Owner and the Development Team to make sure that it's something that everyone believes is achievable. At the end of the Sprint Planning, the Development Team needs to be able to commit to the Sprint Goal.

The Sprint Backlog is the selection of Product Backlog Items for the Sprint as well as a plan for getting them to Done. Scrum doesn't say what this plan looks like, but some teams decompose the Product Backlog Items into subtasks and that becomes the plan. Other teams may produce their plan in different formats. The purpose of planning is to simply give confidence that the team is able to achieve the Sprint Goal and to promote visibility into that progress as the Sprint progresses, up until the Sprint Review where the progress is one of the things reviewed.

The Sprint Backlog is entirely owned by the Development Team. They can change it as they see fit. The existence of the Sprint Backlog is to make the selected work and progress visible to stakeholders. Unless your Development Team spends a whole lot of time planning (which I would not encourage), I would expect the Sprint Backlog to change as other Product Backlog Items are decomposed and the team learns the fine details about what is or is not necessary to get everything to Done.

In traditional, single-team Scrum, I would expect that the Sprint Goal would be fixed. Scrum does allow for the termination of a Sprint, but calls this a "traumatic" event and is not frequent. If your Sprint Goal is regularly becoming outdated or irrelevant, that may be the sign of deeper issues around either your Sprint cadence or the Scrum Team's understanding of what is valuable to the users and other stakeholders. In scaled Scrum, terminating a Sprint early is more difficult since there may be dependencies across teams in order to progress work, so I would expect an outdated Sprint Goal to be handled differently.

Answer 6

As I understand scrum, yes the sprint goal can be changed, with the acceptance of the team - but it is more like restarting sprint than "while running".

The advice I was given when learning scrum was:

• Changing the sprint goal is disruptive and cause problems, so it should be discouraged for stakeholders to request a change. Why is "top of next sprint" not good enough?
• A good discouragement is to "restart sprint" and cancel all sprint goals, including the ones already implemented, in progress, under testing, Done-Done, etc and roll back to start of sprint. Loosing progress is a reasonable side-effect for disruption caused and interrupting work in progress. That is: if change is doable and acceptable to team, and stake holders are OK with loosing current sprint progress and starting over in a later (next?) sprint, then by all means "allow" stakeholders to cause do this - it obviously is important to them if they are willing to reset and disrupt progress.
• Usually "loosing" progress is a wake-up call to stakeholders about how disruptive this is and stop the request (as long as it is top of list next sprint)
• If it does not, perhaps sprints are too long and stakeholders are reacting to this by trying to work around the system (I have seen this happen with "month long sprints", but only had to "reset" on 1 or 2 week sprints twice in 10 years - and everyone agreed it needed to be done in those cases.

(As other poster has noted, it does not really look like OP is actually doing scrum - but scrum-lite or scrum-like, which may be ok for his team, or not)