Sometimes in the middle of the sprint, the customer or product owner submits urgent requirements or requests, which weren’t planned in the sprint planning meeting, and which disturb the smooth flow of the sprint. This often happens when we are implementing Scrum in service operations or a highly complex and unpredictable project.
Although Scrum is designed to allow for flexibility and to handle uncertainty in projects, it still ensures that one sprint is given to the team to focus on a set of requirements that were locked during the sprint planning. If we take on additional demands in the middle of the sprint, it’s a clear violation of the Scrum framework. However, it is hard to refuse the customer or convince him or her that the requests will be taken up in the next sprint. After all, we are working for their dollars.
Here are six strategies that you might want to consider if you have this problem. Other innovative ways might exist, so I would love to hear about them.
- Have a contingency plan. If, as a general trend, many requests are brought up during the sprint planning meeting, set aside some portion of your time to deal with the unexpected. But don’t make it more than 20 percent of the meeting, because you might get into the habit of taking less work in each sprint.
- Achieve the sprint goal. The purpose of the sprint is to achieve the sprint goal. User stories can be added or dropped in the middle of the sprint. So if we have to take up some new requests, our sprint goal should be such that we are able to meet it despite working on some new user stories while dropping a few planned user stories.
- Shorten the sprint. If this is something that happens quite often, then it might be a good idea to have shorter sprints. The shorter the sprint, the better we respond to uncertainty. For example, if we have a one-week sprint, then we can take up the new user story in the next sprint, which is just a week away — as opposed to a four-week sprint, in which the new item can be delivered only after a month.
- Secure customer buy-in. If the customer is willing to understand how Scrum works and the reason behind sprints and iterations, it might be worth getting their buy-in. If we have buy-in, we can safely put it in the product backlog, and it will also help us in future sprints.
- Apply Kanban or Scrumban. If Scrum is not suited for this scenario, Kanban is also an option, as there is no concept of sprints, and requirements can come at any time and be tackled at any point. The only issue is that we’ll have to restrict the work in progress, which can, again, cause problems in managing the work. A blend of Scrum and Kanban, which is called Scrumban, might work. But it’s not recommended, as we might just become sandwiched between the two frameworks and lose track altogether.
- Cancel the sprint. In the worst-case scenario, if because of new user stories the sprint goal becomes totally irrelevant, then we have no choice but to cancel the sprint and start a new sprint by planning and taking new user stories.
There is no right or wrong way. Choose whatever suits your team best without breaking the Scrum framework and annoying the customer.