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.
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 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.
Highlight the downside.
Something else is being delayed
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
Changes can't be implemented untill at least 1 sprint after they are thought of.
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.
- 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.
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)
- 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.