I believe that most of us have encountered this situation. What is the best approach when higher management or client is forcing the PO to include some new functionality in the middle of the sprint, something that is not planned and team did on commit on that?


Just make sure to create a story for the ad hoc work and assign points to it before adopting it into the current sprint as an expedite issue. This way you will maintain velocity. If you had other sprint goals, these will just move to the next sprint.

There is not really a problem here. You can push back a bit though and let them explain why this cannot wait until the next sprint, tell them that it would be more convenient to make it a regular sprint item because you are in the middle of something and these panic assignments are a bit disruptive. Why was this not anticipated? Was someone taken by surprise? If so, why? Can we help to prevent this in the future? Good stuff for the next review/retro/demo.

  • yes, we try to push it back but the problem lies in the fact that i don't think our clients are familiar with scrum framework and its guidelines. For the question regarding why this is not anticipated, we leave buffer on the sprint planning for this moments, however this conflicts with our goal and with the team atmosphere. Jun 23 '19 at 20:09
  • 1
    @DarkKnightSM Can't you just say "will do" and smile and put it on the backlog for the next sprint? The questions I raised are all for you to ask your stake holders. Reserving time in the sprint for ad hoc work is not right. That is not planning. You should plan for proper stories only and if something breaks the sprint, so be it. Jun 23 '19 at 21:24
  • @DarkKnightSM: "i don't think our clients are familiar with scrum framework and its guidelines" - yes, and you should not expect them to get familiar with it. Don't use Scrum terms when talking to the client - translate them to a language they understand. For example, don't ask why this "cannot wait until the next sprint", ask them "why this cannot wait for the next two weeks" (or whatever your timeframe is here).
    – Doc Brown
    Jun 26 '19 at 11:36

In the simplest terms possible, when new work is added to the sprint, some work already in the sprint needs to be taken out. Take the work that was added, do your best to give it an appropriate amount of story points, and then remove that amount of story points from the sprint backlog.

Depending on the size of the request, this can probably happen without too much disruption: just take one story card off of the board and replace it with the new one. However, if they are asking you to make very big changes may require cancelling the sprint and starting over with a new sprint planning session. This has a pretty big cost associated with it, so it's not something you should normally do.

The Scrum Guide has this to say about cancelling a sprint:

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

  • The only thing that I'd note is that cancelling Sprints may not make sense in situations where there are multiple teams. A good practice is to reduce dependencies between teams, this isn't always possible. If one team is dependent on another team, a canceled Sprint could have ripple effects. It may be better to continue on cadence and ensure a stable product at the end of the Sprint rather than abnormal termination.
    – Thomas Owens
    Jun 25 '19 at 16:01
  • 1
    @ThomasOwens: I agree. That's part of why I mentioned big costs associated with cancelling a sprint. For a team working in isolation it might be a minor headache, for a product team made up of many interdependent teams working toward a common release date it could be catastrophic. Jun 25 '19 at 18:23
  • This is the answer which makes most sense to me. However, one should add that "cancelling a sprint" does not necessarily mean to throw away the work which was already done during the current sprint. Instead, the current work can stay in source control (in some unmerged branches) or in source (hidden behind some feature toggle), so the team can continue with that version of the code in a new sprint after the "top-priority feature" sprint is completed. So instead of "cancelling" a sprint, I would suggest to use the term "freeze" instead.
    – Doc Brown
    Jun 25 '19 at 19:13

The contents of a Sprint are not necessarily fixed at the end of Sprint Planning. Based on what the team knows about their capacity and ability to do the work, they have selected items and chosen a Sprint Goal that the Development Team feels is achievable and the Product Owner feels is appropriate to deliver at or before the end of the Sprint timebox.

In an ideal world, the Sprint contents are fixed. However, as you're experiencing now, the world isn't ideal.

If the Sprint Goal has become entirely obsolete due to changing circumstances, Scrum allows for the cancellation of a Sprint. However, this is often a last-resort effort. In addition, in a scaled environment with multiple teams, one team cancelling their Sprint is often not an option.

If the Sprint Goal is generally intact still, the Product Owner and the Development Team can work together to assess the size and scope of the proposed changes and determine if it can be done in the Sprint. Perhaps work that is not yet started can be swapped out for the new work and the work can be delivered at the end of the Sprint. Or perhaps it's too late in the Sprint and the proposed work can become part of the next Sprint.

If the work does become part of the next Sprint, the team can produce an increment at any point in the Sprint and may produce multiple product increments. The only requirement is that, at the end of the timebox and going into the Sprint Review and Sprint Retrospective events, the team has a product increment that meets the team's Definition of Done.

More broadly speaking, the Scrum Master should be coaching not only the team, but other stakeholders, on the principles and practices of Scrum. If the issue is not truly urgent, then it should be possible to wait one or two Sprints to get it. If that's too long, then there may be other things to look at, such as the length of the Sprint with respect to delivering value to stakeholders.

  • thanks, Thomas. I agree, we need to look after over Sprint Goal and decide if something that needs to be done in the sprint has the common value of our goal. So, what you are saying is that team needs to deliver product increment, if not, we are not doing our job properly? Jun 23 '19 at 20:23
  • @DarkKnightSM If you aren't delivering a working increment at least at the end of the Sprint, you aren't doing Scrum. Your increment could reach a "done" state before the end of the Sprint, or you could have multiple increments. But the "done" increment is a key component of Scrum.
    – Thomas Owens
    Jun 23 '19 at 20:25
  • yes, of course. What worries me is that my team is working on multiple projects, so ''done'' increment is sometimes a bug fix on production, sometimes is something that team develops during the sprint, it's a mix of different things, not one project, unfortunately. Jun 23 '19 at 20:29
  • 1
    @DarkKnightSM Scrum is a product development and delivery framework. Ideally, each Scrum Team is focused on a single product. If that's not the case, then Scrum may not be the best fit for you. But that doesn't mean that you can't take elements of Scrum to help build a good methodology for your team and organization.
    – Thomas Owens
    Jun 23 '19 at 20:31
  • Thomas, can Scrumban be a better solution? I read about it, it feels like a better solution, mix of kanban and scrum, did you encounter it? Jun 23 '19 at 20:35

Highlight the downside.

  1. Something else is being delayed

  2. If work already started on that thing then there will be lost time/wasted effort.

But then look at what your are asking from the business

  1. Changes can't be implemented untill at least 1 sprint after they are thought of.

  2. That means 2 sprints before delivery on even a 'small' task.

If the stakeholders like to tweak stuff its not really feasible to have a sprint longer than 1 week.

People accept "we can start than next week and have it to you at the end of that week"

But "we can start that next month and give you it a month after that" is basically a no.

  • Ok, so you propose that if we a lot of things coming during the sprint, we should maybe consider a one week sprint? Jun 24 '19 at 20:45
  • no. I suggest always doing 1 week sprints.
    – Ewan
    Jun 24 '19 at 21:03
  • Do the work. Management and/or the client pay the bills, so the bottom line is they get to decide what to do.
  • In the retrospective, note that you didn't hit your sprint goals because of the unplanned changes.
  • If this happens on more than one sprint, escalate the issue.

Note that you can't just as a development team say "we're doing sprints now" - you have to have buy-in from your customers. If you don't have that buy-in, you either need to get it or work with your customers to create a development process they are happy with.

  • yes, they pay the bills, so we need to do the work. But, does that mean when that happens, we need to remove something from the sprint? And if that happens too often, how would you escalate it? Thanks! Jun 23 '19 at 17:16
  • @DarkKnightSM I too would do the work, but have a conversation with the person changing the priority. Make them decide what’s NOT getting done because the team is working on this new thing. Team capacity to do work doesn’t change just because the priority has changed.
    – RubberDuck
    Jun 23 '19 at 17:47
  • @DarkKnightSM Without knowing more, I assume that the unplanned work is of the scope creep variety (as opposed to fixing a showstopper bug). Yes, you will need to drop something from the current sprint (postpone that until the next sprint). Ask your customers to choose what they are willing to drop from current sprint. Explain to them that changing priorities in the middle of a sprint is disruptive for your team. If this become a pattern (they force scope creep in the middle of every other sprint) then wait until QBR and raise the price. Jun 23 '19 at 17:47
  • thank you for the answers. Yes, i am trying to communicate with the team and management that we need to drop something due to scope change in the middle of the sprint. However, i still don't know how to maintain team's spirit during the sprint because this is frustrating when you need to do this every single sprint. Maybe scrum is not for us, maybe Kanban? Jun 23 '19 at 20:15

One of the big benefits of scrum is

  • transparency (cost and time when features will be done)
  • keeping the developteam productivity (aka velocity) high by protecting it from interuptions in the current sprint like "we should add this unplanned feature as soon as possible" This would become a "add this new feature in the next sprint"

If a feature is so important that it cannot wait until next sprint you loose some of the scrum benefits (transparency and/or productivity)

possible strategies:

  • estimate new feature
  • replace not-started-yet-ticket from current sprint which has similar effort as the new one if possible
  • if not possible stop current sprint immediately and start a new sprintplanning and donot forget to estimate the extra costs/delays caused by interruptions and later-resume

Management has to learn that ad-hoc changes come at a cost. One of the beauties of scrum is that waiting for the next sprint has no additional costs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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