Ticket must be worked immediately, and definitely won't make it to Done by end of sprint

Question

It's the second to last day of sprint. Something comes in from the field that is critical. It will take approximately 2 days to complete. It will not be complete by end of sprint. Other items that are of less importance are given less priority, and the team "swarms" the ticket. Do you inject into the sprint knowing it will get rolled over into the next sprint? Do you put it into the next sprint and have developers actively work tickets that aren't in the current sprint?

Answer 1

Preface

This is such an X/Y problem that no one outside your company can advise except to say "Your process is deeply broken."

Whatever You're Doing, It Isn't Scrum

Nothing you're describing is Scrum-like. There are always bugs, and always new work, but if you don't have fundamental working agreements for establishing a cadence for new work and robbing Peter to pay Paul today then you're not even following basic agile principles, much less Scrum.

While Scrum can be used in other contexts, it's been designed primarily as a product development methodology, not a support ticketing system or a continuous-services framework. The fact that no one in your organization is differentiating between these very different activities is a huge problem.

In particular, the focus on a predictable cadence and cohesive Increments of a Product Goal are not being followed. The 2020 Scrum Guide says:

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality does not decrease;
• The Product Backlog is refined as needed; and,
• Scope may be clarified and renegotiated with the Product Owner as more is learned.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal...[and e]ach Sprint may be considered a short project.

...A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

What you have (not only based on this question, but others you've asked recently) is a process where predictability is not being valued, the Sprint Goal¹ is not being treated as a first-class item, and Scrum Events (which are the defined points at which changes to the project, plan, and priorities are expected to change) are not being properly leveraged. This is an organizational and framework implementation problem, not a "Scrum" problem.

---

1 - The Scope of the Sprint Goal is Tunable but not Fungible

Per the current guide (emph. mine):

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

---

By allowing stakeholders to undermine the cadence and events defined by the framework on an ongoing basis, you basically remove any predictive value from the framework. Not only does this make the whole process not-Scrum, it breaks trust between stakeholders and the Scrum Team, violates working agreements, and is (long term) an untenable way to manage any project.

Make Out-of-Cadence Change Costs and Process Disruption Fully Visible

So, let's talk about the pragmatic politics of your current scenario. It's where you're at, and a by-the-book answer isn't going to help you today.

You're in a situation where you have an "urgent" (as defined by whom?) request that presumably takes precedence over delivering your Sprint Goal or making predictable progress towards your Product Goal². Scrum has a by-the-book answer for that: the Product Owner declares an early Sprint termination, and a return to Sprint Planning with this super-duper important work prioritized to the top of the Product Backlog.

---

2 - "Product Goal" Defined

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Each Sprint is a stepping stone towards the Product Goal, and is built around a singular Sprint Goal that is essential to the current Product Goal. Without a Product Goal you can't do release planning, and without a Sprint Goal you can't create coherent Increments for delivering the Product Goal.

---

Pragmatically, that means that the Product Owner must cancel the Sprint because the Sprint Goal has clearly been de-prioritized by someone outside the Scrum Team. That has consequences for the project, and they must all be made crystal clear to everyone, including stakeholders, project sponsors, customers, the Scrum Team, and everyone else affected.

1. The current Sprint is immediately abandoned; no further work on the current Sprint Backlog will be executed.

2. The current Sprint Goal, which represents an Increment of the Product Goal, is immediately abandoned.

3. Any work in progress, whether or not it yet meets the Definition of Done, is immediately abandoned.

4. The Sprint Review, if one is still held (the current Scrum Guide is silent on this) will explain the reason that the current Sprint has been abandoned, and explain the impact and perhaps engage Sprint Review stakeholders in a constructive discussion about how to more effectively structure the project in future.

   Pro tip: turning this into a blame game is a non-starter. It's about communication, not blame!

5. The "urgent" work is placed at the top of the Product Backlog, and a new Sprint Plan with a single, coherent Sprint Goal built around this top-priority item is created.

6. Depending on the normal length of Sprints, which should not change to maintain predictability, it might still make sense to have a shortened Sprint dedicated to this life-or-death issue if it's a definitely presumed to be a week-or-less issue after triage and refinement, especially if your normal Sprint length is 2-4 weeks.

   Pro tip: To maintain the framework events, the Definition of Done, and other factors, I wouldn't shorten this "emergency Sprint" to less than one week. There may even be arguments for restarting the normal cadence with the new Sprint, which could allow time for fixing the process as well as reducing changes to the "heartbeat of Scrum."

If you get a ton of push-back about early termination, it's reasonable to ask whether this change really needs to disrupt the process or whether it can simply be prioritized for the next Sprint. If not one understands or cares about the framework, this is either a great teaching opportunity or one where the value of Scrum for the organization should become a top-of-mind topic.

"There Ain't No Such Thing as a Free Lunch" (TAANSTAFL)

The main problem with any agile framework, technical work, or organizational process is the expectation that change is free. It never is. Change and disruption have a cost; the problem is that these costs are often invisible, either through a lack of awareness, a lack of transparency, or a desire to sweep it under the rug for political reasons.

Scrum as a framework explicitly requires transparency as a core underpinning of Scrum Theory. One of the twelve principles of the Agile Manifesto also reinforce this:

Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

So, transparency, visibility, and cadence are all axiomatic requirements of effective agility. As a Scrum Master or an agile champion within the organization, it is essential that you communicate both the requirements for agility and the costs of not adhering to the principles to everyone involved. Unless you do that, nothing will change and the organization will eventually assume that Scrum (or agility in general) is to blame rather than fixing the underlying process problems.

There is no silver bullet. Luckily, raining, enlightened self-interest, and good communication are pretty close to being at least silver-plated!

Answer 2

I've used the following hierarchy in the past:

1. Can the work be done in the next Sprint? If so, into the backlog.
2. Do the Developers decide it can be absorbed into the current Sprint w/o endangering the Sprint Goal? If so, accept it.
3. Can you remove some unstarted work that equals or exceeds the 'estimate' of the item being asked for? (This is agreed-upon by the PO and the Team). If agreed do it; unstarted items return to backlog.)
4. Abort the Sprint, and immediately plan/start a new Sprint.

#3 now violates the Scrum Guide's guidance. Given the conditions/constraints you laid out, #4 is the correct choice. (Todd A. Jacobs' answer is absolutely excellent, BTW.)

Answer 3

Since the question is tagged scrum, I will base the first part of the answer specifically on the Scrum framework.

Only Developers can accept work into the Sprint. The Sprint Backlog, which includes the Product Backlog Items selected for the Sprint and a plan for delivering Increment(s) during the Sprint, is "a plan by and for the Developers". No one can force the Developers to take on a piece of work. The Product Owner may assess the importance, criticality, value, and other aspects of the work and hold a conversation, facilitated by the Scrum Master, with the Developers about starting this work. The conversation should focus on the Sprint Goal. If the Sprint Goal hasn't been achieved yet, there needs to be some consideration about achieving the Sprint Goal that was a commitment to key stakeholders versus completing this one piece of work.

If the Developers do accept the work into the Sprint, transparency becomes key. Not adding the new work to the Sprint Backlog and making this change in work visible to stakeholders would not be consistent with valuing transparency. If the Developers do not achieve the Sprint Goal, having this visibility into the new work can make the impact visible to key stakeholders at once and give rise to a discussion at the Sprint Review and Sprint Retrospective.

It's important to keep in mind that Scrum is not about completing bodies of work. It is about achieving goals and delivering Increments of valuable products and services. The Sprint Goal is a commitment by the Developers.

Stepping away from the Scrum framework, we can also take advice from the underlying values and principles of agility.

Agility is about responding to change. Customer satisfaction is also a high priority for agile teams. The most agile thing to do would be to ensure that your way of working supports a suitable response time to make the requested changes. That means starting the work as soon as possible to deliver it.

Regardless of the decisions of the team, they should spend some time to improve their effectiveness by looking at the root causes for the critical change, determining why it became so critical that it could not wait for the team's normal planning and delivery cadences. This type of disruption should be minimized, and the application of root cause analysis and retrospective activities can help.

Answer 4

Under Scrum, the Scrum Team makes a commitment during Sprint Planning to delivering a particular Sprint Goal by the end of the Sprint. This Sprint Goal is based on (a) what the Product Owner has determined is the most valuable work on the Product Backlog, and (b) what the Developers have determined is feasible to deliver within the Sprint.

Whose decision is it that this new work "must be worked on immediately"? Because if the answer is "someone outside the team", that means the Scrum Team lacks the autonomy they need to perform their role. If the answer is "someone inside the team", then either:

1. The work is something that invalidates the Sprint Goal, in which case the Product Owner should cancel the Sprint and the Scrum Team should swarm on the new work to understand it and determine a plan for a new Sprint that incorporates it.

2. The work is something that turns out to be essential for the Sprint Goal, which wasn't previously identified. In this case, the Developers should swarm on this new work to understand it, and work with the Product Owner and Scrum Master to make a plan based on this information (including the fact that presumably the Sprint Goal cannot be delivered by the end of the Sprint).

3. The work is irrelevant to the Sprint Goal, and in fact it's not something that "must be worked on immediately". The Product Owner puts it on the Product Backlog, and the team can consider it in the next Sprint Planning.

In all cases, it would probably also be a good idea for the team to reflect on this at the next Retrospective and see if there's any way to anticipate or prevent this kind of work interrupting the Sprint in the future.