Sprint Scope Change

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? 

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.

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.

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.

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?

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.

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.