Skip to main content

Sprint Scope Change

Last post 12:59 pm October 8, 2019 by Jaca Perc
7 replies
02:40 pm October 3, 2019

I have one team that is making a lot of changes during the sprint, bringing a lot of tickets and removing some. They are good in deliveries, so whatever they commit they deliver. I'm having a hard time to explain why is that not good. Looks like they underestimate. I tried to explained them but they think it's all about the admin.Any thoughts?


02:52 pm October 3, 2019

The important questions is are they committed to delivering sprint goal agreed upon? If they are delivering the sprint goal, I would not worry much, except in a case where they are creating an additional technical debt that needs to be taken care of in the future sprints.

Looks like they underestimate. 

What suggests to you that they underestimate?  

Additionally, you should also investigate if they are creating any dependencies for any other team? 


03:17 pm October 3, 2019

How are they changing the Sprint?

During the Sprint Planning session, Product Backlog Items are selected and a Sprint Goal is formulated. Is the team making changes to the selected Product Backlog Items over the course of the Sprint? If so, is the Sprint Goal in jeopardy?

I would expect, that over the course of the Sprint, the Sprint Backlog would change as information is learned and the plan is adapted. I would not expect changes to the selected Product Backlog Items or the Sprint Goal without the involvement of the Product Owner.


04:56 pm October 3, 2019

I agree with Thomas. What is the Product Owner's involvement in these decisions?

If the teams are committing to anything, you would want it to be the sprint goal and not the individual stories. Is the concern based on the activity of pulling in work and taking some out? If so, I would dig into the reasons for those decisions.

If it's a matter of team learning something and realizing the original plan needed updates but the sprint goal remains in tact, then you want to encourage the updates to the sprint backlog because you're delivering on the expectation of the increment and not how clean the burndown looks.

I don't know the benefit of taking work out of the sprint because it's nice to be able to visualize these types of decisions. If you add 3 points and remove 3 points at the same time, then it appears like a tiny blip that can be ignored which affects transparency. However, that concept is debatable.


08:19 pm October 3, 2019

Usually they are not changing the sprint backlog items that were brought into the sprint..they add bugs and changes that are not part of the sprint backlog items or the goal. They underestimate as they have time to bring 20 bugs and finish all. I tried to push to bring more tickets during the planning even if we expand the goal, but they are saying their estimate is good.


08:41 pm October 3, 2019

Usually they are not changing the sprint backlog items that were brought into the sprint..they add bugs and changes that are not part of the sprint backlog items or the goal. They underestimate as they have time to bring 20 bugs and finish all. I tried to push to bring more tickets during the planning even if we expand the goal, but they are saying their estimate is good.

Do you think trying to push more work onto the team, instead of encouraging them to improve the quality of work "Done", is a wise strategy?


10:58 pm October 3, 2019

Usually they are not changing the sprint backlog items that were brought into the sprint..they add bugs and changes that are not part of the sprint backlog items or the goal. They underestimate as they have time to bring 20 bugs and finish all. I tried to push to bring more tickets during the planning even if we expand the goal, but they are saying their estimate is good.

Are you saying that, during Sprint Planning, they produce a forecast that is extremely under what they can achieve and, throughout the Sprint, bring in additional work?

To me, this would prevent the Product Owner from optimizing the work done in the Sprint to focus on delivering the most value. I'm curious as to why the team thinks this is a good thing to do. Do they feel that the Product Owner would not prioritize known bugs, issues, or technical debt? Or is there some other reason.

I'd also point out that the goal is not simply a mapping of the Product Backlog Items. The Sprint Goal can be related to 1 or more of the Product Backlog Items selected for the Sprint. Personally, I try to ensure that the Sprint Goal can be achieved by completing about 60-70% of the selected Product Backlog Items. This helps to allow the team to commit to the goal and still be able to adjust for unplanned events happening. Different teams may have different ideas on how much of the Product Backlog Items should be accounted for by the Sprint Goal, though.


12:59 pm October 8, 2019

Thomas, yes you are right. That is what I think. We are trying to make sure they understand the issue with the underestimation. I don't think they understand the problem, they like to have it less and then bring the items as they go. 


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.