The Change Management Situation

My Scrum Team received 2 urgent and critical tickets from top management at the end of the Sprint with 3 days left. The tickets were related to a feature that was to be announced in 2 days. The feature is ready and working, but top management came up with 2 additional UI improvements that they want to see by the time of announcement. Those tickets don't match the current Sprint Goal, and I don't agree with their status of "critical," but the request is to do them ASAP.

In order to complete them we'd have to stop working on some remaining tickets. Even then, the critical tickets wouldn't be ready by the Sprint Review. So, accepting working on them would ruin the Sprint.

In order to prevent ruining the Sprint, I suggested 3 possible options:

  1. Work on the tickets in the scope of the next sprint in 3 days and release UI changes after the feature is announced.
  2. Cancel the current sprint and plan the next one with the critical tickets, but this means a 1-day delay.
  3. Assign the tickets to another Scrum team that works with the same product and has their sprint just started. The problem is that they are not that familiar with the feature, so they wouldn't do tickets as fast as my team.

All 3 suggestions were refused, and the change request remained unchanged. My team had to work on the tickets, and I was called inflexible.

The Core Question

What should I have done in this situation? Are there other solutions I should have considered other than the three I already gave?

  • What is the relationship between the Sprint cadence and the announcement of the feature? How many days or Sprints are between the time you were asked to do the work and the announcement where they wanted the work done? Even if the team dropped everything immediately, would they have been able to get the work done on time and consistent with their Definition of Done?
    – Thomas Owens
    Commented May 29, 2023 at 19:14
  • @ThomasOwens there's no direct relationship. We release the increment in the end of the sprint, but the announcement of the feature might be in 1 week, or as with this specific feature, 2 weeks after the release.
    – f0rtis
    Commented May 30, 2023 at 7:23
  • @ThomasOwens Also, nobody propagated the announcement day - we heard that the feature must be announced in 2 days and we need to do critical adjustments before that. And, even if the team dropped everything immediately, there was a high chance that work wouldn't be done by the end of the sprint.
    – f0rtis
    Commented May 30, 2023 at 7:52

4 Answers 4


My preferred approach in this situation is to do the requested work as quickly and effectively as possible.

Then I would:

  • Detail the impact the last minute change had on the team and report it
  • Coach the people involved on why we try and avoid this kind of unplanned change
  • Bring the incident to the next team retrospective and think about how in the future you might better handle this kind of request

Try and avoid pushing back against last minute requests until the people involved are better educated on the impact they are having. This stops you being seen as the 'enemy'.

A report might look something like this:

In the last sprint we had planned to get the new search feature finished, but a last-minute feature request meant we were unable to. We have apologised to the stakeholders impacted by this. The team also spent time context switching which reduced our output from the sprint by about 20%. It is likely to also have an impact on the next sprint. The team will work on ways to improve the way we deal with last minute requests so that we can reduce the overall loss in produtivity that results.



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

  1. 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:

  1. 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.
  2. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.


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.


(Assumption: 'top management' does not include the project owner(s))

We can discuss what is wrong with your Scrum structure ('top management' telling you what to do without going through the product owner), but that does not help you right now. It sounds that you are going to have to make these adjustments anyway.

Ask your product owner to ask from 'top management' that they agree that if you take on X and Y, that A, B and C will not be completed later than originally planned. By mail, of course, so that you have it in writing.

If this is a one-off thing, don't worry about it further. Scrum does not carve in stone how things MUST be handled.

  • Thanks, @Jan. You’re absolutely correct about the structure. Moreover PO himself is more like a proxy, rather than a person with authority. Of course I’ll try my best to explain why it’s bad, but I have doubts that top management will agree to have less power.
    – f0rtis
    Commented May 29, 2023 at 18:24
  • 1
    OK, then it's clear that your organization is not really adopting agile, but that's for another time (another question?).
    – Jan Doggen
    Commented May 29, 2023 at 20:55

I think I'm working in same situation with you.
Here is my overall comment:

  • I think we should to understand the organization and how we apply Scrum framework.
    • If you apply Scrum framework, then we (Scrum Master) need to understand how to apply & making sure PO, SM, Development team do the right Scrum framework as expectation
  • Please do not recognize that we think "we're doing Scrum" but in fact, we just pick/apply some practices of Scrum and management viewpoint or processes still be old style.
    • In this situation, Top management can not decide any priority of work during sprint. It's responsibility of PO, Development team. Of course, in the worse case Product Owner will accept priority of Top Management. At that time, please keep in mind we (all related stakeholder) must to follow Scrum framework to handle. Maybe, we can do same as your suggestion (cancel current sprint & start new sprint).

With above information, I think your team & organization is mixing between traditional & agile/scrum management.
My solution is:

  • As management, when customer request anything then our team need time to estimate and provide the plan/schedule to finish product.
  • As traditional management, if cost is high and customer want to release as specific deadline (As your situation is next 3 days). So, top management need to add/allocate more resource. If no, change release milestone.
  • As Agile/Scrum, we always need to understand/courage business viewpoint from related stakeholder/PO/... we always cooperate to earn highest value in mindset.
  • As Scrum, when we have decision then keep 3 characteristic of scrum (Transparency, Inspection, Adaptation )

That's my comment & solution which I'm applying.
If you have any comment with my way, please feedback.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.