Skip to main content
Project Management

Return to Question

Refactor question for clarity and to fit the Q&A format. Minor grammar, semantic, and formatting improvements throughout. Retagged.
Source Link
Todd A. Jacobs ♦
Todd A. Jacobs ♦
  • 50.7k
  • 7
  • 60
  • 181

Handling How can we handle urgent work initems defined by leadership at the end of the sprinta Sprint?

I'm interested in what would you do in the situation I found myself.

The Change Management Situation

The situation that happened with me recently - myMy Scrum teamTeam received 2 urgent and critical tickets from top management inat the end of the sprint(3Sprint with 3 days left),. The tickets were related to a feature that should have beenwas to be announced in 2 days. For a better understanding - theThe 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 sprint goalcurrent Sprint Goal, and I don't agree with their status of critical"critical," but still, the request is to do them asapASAP.

In order to complete them we'd have to stop working on some remaining tickets, and still. Even then, the critical tickets wouldn't be ready by the Sprint Review meeting. 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;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. My team had to work on the tickets +, and I was called not flexibleinflexible.

The Core Question

So guys, if you wereWhat should I have done in the samethis situation, what would you do? Agreed with the request, stand for one of the suggested options, or maybe youAre there other solutions I should have considered other ideasthan the three I already gave?

Looking forward to reading your ideas and advice.

Handling urgent work in the end of the sprint

I'm interested in what would you do in the situation I found myself.

The situation that happened with me recently - my Scrum team received 2 urgent and critical tickets from top management in the end of the sprint(3 days left), related to a feature that should have been announced in 2 days. For a better understanding - the feature is ready and working, but top management came up with 2 UI improvements that they want to see by the time of announcement. Those tickets don't match the sprint goal, I don't agree with their status of critical, but still, the request is to do them asap.

In order to complete them we'd have to stop working on some remaining tickets, and still, the critical tickets wouldn't be ready by Sprint Review meeting. 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 request remained unchanged - my team had to work on the tickets + I was called not flexible.

So guys, if you were in the same situation, what would you do? Agreed with the request, stand for one of the suggested options, or maybe you have other ideas?

Looking forward to reading your ideas and advice.

How can we handle urgent work items defined by leadership at the end of a Sprint?

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?

Source Link
f0rtis
f0rtis
  • 121
  • 2

Handling urgent work in the end of the sprint

I'm interested in what would you do in the situation I found myself.

The situation that happened with me recently - my Scrum team received 2 urgent and critical tickets from top management in the end of the sprint(3 days left), related to a feature that should have been announced in 2 days. For a better understanding - the feature is ready and working, but top management came up with 2 UI improvements that they want to see by the time of announcement. Those tickets don't match the sprint goal, I don't agree with their status of critical, but still, the request is to do them asap.

In order to complete them we'd have to stop working on some remaining tickets, and still, the critical tickets wouldn't be ready by Sprint Review meeting. 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 request remained unchanged - my team had to work on the tickets + I was called not flexible.

So guys, if you were in the same situation, what would you do? Agreed with the request, stand for one of the suggested options, or maybe you have other ideas?

Looking forward to reading your ideas and advice.