Get certified - Transform your world of work today

Close

Tackling Urgent Requirements in the Middle of a Sprint

21 June 2016


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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (2 ratings)

Comments

Tim Baffa, CSM, 6/24/2016 4:11:44 PM
In my experience, the easiest approach to take with Product Owners who are unfamiliar with sprint cadences, and are used to giving orders at any time, is as follows:

The team made a forecast, to the best of their ability, around work they feel capable of completing by the end of the sprint. If the PO insists that a new priority must not wait, they need to understand that the sprint backlog cannot just expand to accommodate additional work.

If the PO wants to introduce scope mid-sprint, then they need to offset it by working with the team to remove a somewhat equal amount of low-priority scope from the sprint.

An important consideration is the state of the new work. Does it meet the Definition of Ready? If not, then there is a significantly larger effort involved (grooming, analysis / understanding, meeting DoR, estimation, etc.) that puts the current sprint work at risk.

The retrospective is equally important to discuss the reasons for the late story offer, and what can be done to mitigate such a disruptive event in the future.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe