Adapting Capacity for Additional Task in an Active Sprint and impact on Sprint Goal

If an adaptation to the Sprint Backlog makes it more likely that the Sprint Goal is achieved, the Developers should implement the change; if the adaptation would make it less likely, they should not.

A personal opinion of mine that I appreciate not everybody will share. For technical scrum questions like this one, I often use the Agile manifesto entry of "working software over comprehensive documentation" as a guideline. 

Our main aim is to deliver working software for the high priority items.  What need to be done to achieve this?

(Sprint goal can be substituted for high priority items.)

If the team has planned work to the point of not being able to handle emergent work, then the team has planned to do too much work in the Sprint.

A small amount of undiscovered or emergent work should not put the Sprint Goal at risk or affect any of the planned Product Backlog Items. The team should have room to pull in a high-priority stakeholder request, address the potential need for rework, or pay down technical debt. To the extent possible, root cause analysis can determine why these work items emerged, if there was any way to foresee or prevent them, and make the necessary improvements.

Typical example is if QA test fails, and the dev have to do a rework or if there is a bug that need to be fixed, tech debt etc. 

This answer may not be what you want to hear but it is my opinion. If the QA test fails for work done during the Sprint, then that rework should already be accounted for during that Sprint.  However, if your Scrum Team gives their Sprint increment to another team for testing then the QA test failure has just discovered something that needs to be done to improve the Product and that work should go into the Product Backlog to be refined and ordered appropriately. Same could be said for any other bugs that are found outside of the work that is being done in the Sprint. 

If these defects or bugs are being found in the work done during the Sprint, then your Developers need to learn from this that they do not produce perfect work and they need to plan to have time to deal with these situations. 

I advocate that tech debt be treated just like anything else that needs to be done to the Product. It should be captured in the Product Backlog and ordered appropriately.  The difficulty in this is that sometimes the Product Owner will not understand the value of addressing that debt so the Developers have to help them understand.  For example, the Developers can explain to the Product Owner that if they do not address a specific part of tech debt, it will make introducing the a specific new feature 3 times more difficult.  That way it can be ordered appropriately in the Product Backlog. 

Scrum is built upon empiricism. Empiricism is grounded in continuous learning.  If the Developers are not providing time for empirical discovery and adjustment, then they are trying to do too much in their Sprints.

Personally I like the answer of Daniel White the most. In the nutshell, it is always worth remembering that whole purpose of Scrum vs other Agile or Waterfall frameworks, methodologies or whatever is to DEAL WITH PROBLEMS EARLY.

Scrum team should never treat refactoring or failure to meet Sprint goal as an emergency or ingoing problem. 

On the contrary, its an asset in a form of the empirical lesson to learn, and insurance mechanism which allows to detect problems early on a project.

Just like you should not remove beeping fire alarm to solve problem of beeping, and should search around for signs of fie; you should not try to urgently reformat your sprint when the Scrum framework allows you to spot hidden hazard. You should take it as ordinary working situation.

You surely know what to do if increment will not meet Definition of Done. 

Move PBI back to Product backlog, adress the issue both at Sprint Revue and Retrospective, figure out the reasons, solutions and outcomes, update DoD and plan next Sprint better...

Good luck

Of course, IF the Sprint goal does not change and IF quality does not decrease, you may update current sprint instead of failing to create increment(which , I repeat is a normal situation, not a drama). But you should be very careful with it. Instead of having COURAGE to accept the situation and OPENLY facilitate explination to stakeholders, team, SM or PO might actually decide to ignore possible technical debt , change DoD and push the increment disregard. 

Which will only cause more problems in a future when technical debt will start kicking in.

How do you deal with production bugs that are emergencies and that you have a very short window to fix (days). You'd have to squeeze these into your sprint, and they might affect your sprint goal. I've seen this happens many times.

How do you deal with production bugs that are emergencies and that you have a very short window to fix (days). You'd have to squeeze these into your sprint, and they might affect your sprint goal. I've seen this happens many times.

A few things come to mind:

1. Use the Sprint Retrospective to generate insights about the production bugs and emergencies and have the Scrum Team strengthen the Definition of Done to prevent bugs from re-occurring.
2. If you have empirical evidence of how often bugs occur, until you strengthen your Definition of Done, teach the Developers not to plan at 100% capacity to handle these unexpected issues.
3. Use the Sprint Goal to guide the conversations between the PO and Developers. Is the bug more important than accomplishing the Sprint Goal? Can it wait to be fixed in the next Sprint?
4. Empower the Product Owner to say 'no'. All too often, these bugs are not critical and can wait and distract the Developers.

Scrum on!

How do you deal with production bugs that are emergencies and that you have a very short window to fix (days). You'd have to squeeze these into your sprint, and they might affect your sprint goal. I've seen this happens many times.

This situation seems different from Developers perspective, from Scrum masters perspective and from Product owner perspective.

While developers and PO can feel pressure to revise the Definition of Done and add a few additional things to the Sprint Backlog in order to release an increment bug-free, the Scrum Master should constantly be checking to see whether those changes are endangering the Sprint Goal and if quality is not suffering.

Please keep in mind that failing to meet the sprint goal and being unable to make an increment during the sprint are simply functional aspects of scrum, not some tragedy.

If bugs are so crucial that increment can be released, and working in a same cadence does not allow fixing them, simply accept the situation, don't present the increment at Sprint review, discuss this with stakeholders, and explain future steps.. Bring the necessary elements back to the product backlog, talk about the issue at the sprint review, create a better definition of done, add properly shaped items to the sprint backlog for the following sprint, and let the increment be born when everything is ready according to updated DoD.

Keep in mind that Sprint Review is not a gateway for presenting the increment.

Anytime during the sprint, an increment can be created and provided to stakeholders.

Therefore, if fixing the bugs will only take a few days following the Sprint retrospective/end of the current Sprint/start of a new one, it will only result in a short delay in finishing the increment. Without disrupting the flow and cadence of work or running the risk of incurring technical debt.

Given that if a task is added to the Sprint Backlog, something must be taken out, can we also update our Sprint Goal or just continue work and make a note on why the Sprint Goal was not achieved or why there was no increment?

I think it is worth paying a closer look into the Sprint Goals being set.

Per Scrum Guide: "Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it."

A simple example might be:

The Sprint Goal is to provide Users with the option of paying with a credit card.

There is a number of PBIs associated with this goal pulled from the Product Backlog to the Sprint.

One of them is "As the User I want to have my Credit Card number validated directly on the webpage before I hit submit button so that my transaction is not rejected due to an invalid number"

So, even if we remove this PBI, it doesn't mean the user won't be able to pay by credit card.

Or maybe there are some other PBIs, which have some fancy additions which are not crucial for the Sprint Goal if done much simpler way?

There is a number of PBIs associated with this goal pulled from the Product Backlog to the Sprint.

One of them is "As the User I want to have my Credit Card number validated directly on the webpage before I hit submit button so that my transaction is not rejected due to an invalid number"

So, even if we remove this PBI, it doesn't mean the user won't be able to pay by credit card.

Yes, but if all competitors already have credit card verification in place, it can result in considerable technical debt.

The product owner and scrum master should agree on what is more crucial given all deadlines and market demands: to create and possibly replace increment early, even if doing so means adding technical debt to the product backlog (or creating it covertly in shadows), or to delay the increment to achieve higher quality and explain it to the stakeholders at the Sprint reveuw

The product owner and scrum master should agree on what is more crucial given all deadlines and market demands ...

Why should the Scrum Master be part of that discussion?  They play no role in delivering any of the actual work.  That discussion should be between Product Owner and Developers because the Developers are doing the work and better know the ability to get things done.  Sometimes the customer request can't be met without first paying down some technical debt. If the Developers are not involved in that discussion, that may never be known. The Scrum Master has no accountability in this situation.  Their accountability is to ensure that the Product Owner is responsibly managing the Product Backlog.

Also, in the example that Jacek used, he is completely correct.  That one item could be removed from the Sprint Backlog and not impact the Sprint Goal.  Your response has nothing to do with the Sprint Goal, it is about the Product Goal.  Also, there is nothing stated in the Scrum Guide about increments being pushed to production use.  The increment can be complete, valuable, satisfy the Sprint Goal and be reviewed with stakeholders but never released to the general public. As you stated, the Product Owner is the one that decides what is more crucial but the Developers are the ones that decide what work will be done during a Sprint.

Why should the Scrum Master be part of that discussion?  They play no role in delivering any of the actual work.  That discussion should be between Product Owner and Developers because the Developers are doing the work and better know the ability to get things done

That's true by definition, but there is no obstacle in Scrum guide which prevent Scrum master from being part of this discussion, either directly, if he is invited or indirectly by asking questions to Product owner and Developers.

Of course Scrum master has no power to prevent change of the DoD and the presentation of increment if developers and Product owners agree on that. But good Scrum master should have lots of coaching, mentoring and facilitation techniques to influence this decision.

And while doing that, Scrum master has to establish the priorities about technical debt and release of increment; both for himself and for the team. As openly as possible.

I, in managing an active Sprint, advocate maintaining the Sprint Goal amid emergent tasks. Adhering to the "something in, something out" principle ensures balance. If unavoidable additions arise, collaborative decisions on updating the Sprint Goal may be considered, maintaining transparency in cases where it's unachievable. Documentation of deviations supports retrospective insights for continual improvement in Agile practices.

you can check this : 

https://www.scrum.org/resources/blog/myth-2-sprint-backlog-cant-change-during-sprintblue prism training