TL;DR
The goal of Scrum is not to prevent change. It simply makes the cost of change visible, and the impact to the team's processes and cadence transparent to stakeholders.
The Sprint Goal is not a money-back guarantee. It's an estimate, and can be changed even at the last minute provided the cost of that change is clearly communicated. This may include abandoning other work-in-progress to meet the changed requirements. That's most likely what should have been done in this case.
I'll give you a step-by-step breakdown of how to handle this sort of situation in an agile way without abandoning either the framework or its underlying principles. You may still have to bend them a little to make it work, though, assuming it can be done within the requested deadline at all.
Length Warnings
- Approximately 2,000 words ahead.
- Please caffeinate sufficiently before proceeding.
Analysis and Recommendations
Overview of Practical Options
- Cancel the current sprint and plan the next one with the critical tickets, but this means a 1-day delay
If you're given two days to work on new features, one is forced to assume that someone thinks the work can be done quickly, even if it comes at the expense of other work. That should be clearly communicated upwards, but if the work is urgent, takes priority over current work, and can be done within the allotted time for the remainder of the current Sprint or in a new short-term Sprint, then it can and should be done without violating the mandatory events to the maximum extent possible.
This leaves you two realistic options:
- Cancel all other WIP for the current Sprint, devote a couple of hours (you shouldn't need more for 2 days of work if it already meets your Definition of Ready for a last-minute change), and have a mini-Sprint Planning session for the new work.
- Abandon the current Sprint in its entirety (see last paragraph of 2020 Scrum Guide § The Sprint), and start a new cadence with the priority work as the new Product/Sprint Goals.
Based on the way your question was phrased, it seems like the first option I listed would be the better fit. Let's talk about how to do that.
Step-by-Step Recommendations for Re-Planning
Here's how you do it without violating core Scrum events and principles.
Do a super-quick refinement activity on the requested work.
The sole purpose here is to determine if you can do it within the "mandated" two days regardless of other considerations. Just as nine women can't have a baby in one month, just because there's a deadline doesn't mean it's actually achievable. The purpose of this triage refinement is to see whether the work can even be delivered as requested within the time frame, regardless of other considerations.
All changes to the Product Backlog must go through the Product Owner.
If the Product Owner was not involved in this last-minute set of changes then involve them right away.
Have the Product Owner formally cancel the current Sprint, if necessary.
The Product Owner is the only role authorized to declare an early termination to the current Sprint or to negotiate a change to the current Product and Sprint Goals. Formally, the Sprint should be canceled, but for purely practical reasons the Scrum Team may simply redefine the current Sprint Goal to meet the new Increment being defined by your leadership team.
The benefit to changing the Sprint Goal rather than canceling the Sprint is that it side-steps the requirement to change the normal Sprint cadence, re-plan rather than go through other mandated framework events, and focus on the new objective rather than worrying about the old one. The Scrum Guide says the Product Owner must cancel the Sprint if its goal becomes obsolete, but another way to look at this one-off situation is that you are simply postponing the current Product Goal, Sprint Goal, or Increment.
[The Scrum Team] must fulfill (or abandon) one objective before taking on the next.
Since this is supposedly a one-off, there's potential value in treating this case as a short-term change to the Sprint Goal rather than an abandonment of a Product Goal. This is admittedly a bit of hair-splitting, but it has some practical benefits that I'll try to outline below.
Abandon all current work-in-progress.
Regardless of whether this is a full early termination or simply a radical change to the current Sprint Goal, all existing goals have been wished into the cornfield. Spend zero time on this fact now. The Scrum Team can address it properly with stakeholders within the next full Sprint Review, and as a process issue for the team in the next full Sprint Retrospective. The Product Owner and Scrum Master might even address it outside the framework with your leadership team without derailing work on the current emergency.
In any case, unless already delivered any work left undone is simply returned to the Product Backlog for future consideration. This is often a culture shock to organizations that haven't fully embraced Scrum, but allows the team to focus on goals instead of tickets or work items, and encourages the organization to embrace re-prioritization as a way of managing some of the costs of change.
If it's full cancellation, do a 30-minute mini-retrospective.
A formal cancellation requires that the team end the Sprint and hold required Sprint events. This used to be more explicit, but currently it's implied by the fact that you've essentially turned the standard time box into a shorter one so you can start a new one. The old time box still requires an inspect-and-adapt cycle, while the new one still requires planning.
On the other hand, simply redefining the Sprint Goal just requires re-planning the current Sprint Backlog. This can be done in an hour or two (maybe even less) if you're just planning for two days of reasonable work effort.
As explained above, if it's a full cancellation then you're required to do a Sprint Retrospective. Keep it short and focused, since you already know what the core process problem for the Scrum Team is. This special Sprint Retrospective should probably focus on how to make the cost of last-minute changes more visible, and how to collaborate better with stakeholders to avoid last-minute changes whenever possible. They may not yet fully understand the cadence, or be collaborating closely enough with the team. While you should focus on the current emergency, don't allow this teachable moment to pass!
The primary outcome of such a retrospective should be to determine how the Scrum Team as a whole wants to collaborate with leadership in future to prevent expensive last-minute changes in the future, and perhaps empower the Product Owner and Scrum Master to speak on their behalf with practical alternatives or improved communication.
Don't make it a complaint-fest. Just reach a quick consensus on the issue, and postpone everything else for the next full Sprint Retrospective, which will be in just three days if you're keeping your existing cadence.
Aside: Consider Postponing the Retrospective
If you're abandoning the current Sprint in its entirety then you might choose to postpone the retro while acknowledging that it violates the formalism of the Scrum framework. The cost of breaking cadence and its long-term impact to the project should be clearly communicated at the appropriate time, which is primarily the job of the Product Owner in this case, but the Scrum Master should probably collaborate on that with them as part of that role's framework-coaching service to the organization.
NB: It's better to break the rules than to break the spirit of the rules. If you have to make a choice, then focus on the meta rather than trying to be a Scrum lawyer; it won't change anything, especially in a toxic organizational culture.
Build a new Sprint Backlog for the urgent work that has made the previous Sprint Goal obsolete.
With only two days to deliver, which I'm interpreting as a management fiat deadline rather than simply the time remaining in the current Sprint, you should not include any other WIP or Product/Sprint Backlog items that aren't directly related to delivery of those time-sensitive work items. Assuming each item is about the same size and not necessarily complex, one to two hours for a mini retro and mini planning session are probably all that's really needed, assuming the new goal and scope can fit within that time box in the first place.
Make the new Sprint Backlog clearly visible to the entire Scrum Team as well as stakeholders.
This should be the case anyway, but it's especially important when cadence is disrupted for the level-of-effort to be clearly communicated to everyone involved with the project. This is doubly-true if the Scrum Team is abandoning a sustainable cadence for emergency work that requires overtime, shortcuts, or taking on technical debt in order to meet requirements outside the normal cadence.
While emergencies happen, continual firefighting isn't sustainable and leads to project death marches. That's one of the goals inherent in making the cost to the Scrum Team and to the overall product delivery goals fully visible; this won't guarantee they won't recur, but it makes it clear that while the Scrum Team embraces change, that change still creates a cost to the project.
Deliver each Increment as soon as it meets the Definition of Done.
You don't have to wait until the end of a Sprint to deliver the newly-defined work items. Deliver them as soon as they meet the Definition of Done. Whether or not this new Sprint Goal is met becomes grist for the mill for the Sprint Review and Sprint Retrospective; you shouldn't treat the end of the Sprint as a gating activity to release or deliver completed Increments.
Pragmatically, it's better to deliver completed Increments that meet the Definition of Done that it is to meet the Sprint Goal especially in situations like this. If the team does their best but can't meet an unreasonable fiat target, at least they will still have something to show for their efforts, and that is important political currency.
Hold your normal Sprint Review and full Sprint Retrospective.
Whether on your regular cadence or not, this is the opportunity for the Scrum Team to discuss the progress that was made (or abandoned) during the current Sprint. If the new Sprint Goal was met, that should be clearly communicated. If neither goal was met, it's an opportunity for the team to collaborate with stakeholders on adaptions to the working agreement. The 2020 Scrum Guide says:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
Be constructive and collaborative. Your goal is to articulate what was delivered, and to identify next steps. Turn any blame or finger-pointing into Product Backlog items to carve out time to collaborate on new and better working agreements instead.
Summary
Any kind of coaching or project leadership role is essentially a position with accountability without authority. It shouldn't be this way, but it is.
It's probably not fair for your line management to tell you to follow Scrum and then discard its core requirements for collaboration and respect for time boxing. However, they are not necessarily wrong in saying that defending the sanctity of the current Sprint Goal at all costs, or the one-day time box the team has defined for standard iterations, seems less than fully adaptable.
Depending on your level of experience, it is very likely unfair of leadership to expect someone without a great deal more experience with Scrum and other agile frameworks than the typical Scrum Master to know how to "embrace change" based solely on the guidance in the Scrum Guide or the knowledge demonstrated in a Scrum certification. Scrum often tells you what and occasionally why, but doesn't really provide a ready-made toolbox of how. This is one of the criticisms often leveled at Scrum, which is designed to provide validated learning based on experimentation rather than a set of concrete practices outside of the mandated events.
Make sure you ask your leadership for more framework coaching, both for them and for the team, so that everyone can be on the same page in the future. In the meantime, you now have a step-by-step set of techniques for handling unexpected change. Communicate that you and the team have added to your toolbox, and how leadership can use that lever more effectively in the future. This kind of honest and open communication is the best way to show that you are adaptable, and that Scrum and your Scrum Team are too.
