Over a million developers have joined DZone.

Dealing With Unplanned Work During the Sprint

DZone 's Guide to

Dealing With Unplanned Work During the Sprint

Unplanned work can be a headache in the middle of a sprint. Check out the novel approach that one Scrum Master took to solve it.

· Agile Zone ·
Free Resource

Unplanned Work Issue

Recently I've joined a new company as a Scrum Master and faced a challenge that I have never had before. I was assigned to three Scrum teams that had different levels of experience with Agile and Scrum. One of the teams was completely new to Scrum and another team was practicing it for more than two years. But all three teams had the same type of issues—they had to deal with unplanned work during the sprint.

Image title

Attempts to Resolve the Issue

The recommended Scrum approach for this type of issues is to have short sprints. This helps to stick with the team's original sprint plan and a new unplanned work can be selected for the next sprint that is coming soon. But the nature of the company's business makes it mandatory to take care of some user requests immediately. So, short sprints don't work.

Another attempt to resolve the issue was made by one of the teams at the Scrum training they had before. They described the situation to the Agile coach who provided the training and he recommended to have a separate support team to deal with those user requests. But this solution wasn't feasible either.

The teams kept trying to find a reasonable solution. They used focus factor to plan their sprints and they decided to experiment with it to have at least some of their sprints successful. They tried to plan sprints with focus factor of 70% "productive" and 30% "unproductive" time. Then they tried 60% - 40%, 50% - 50%. None of those worked since the amount of unplanned work was absolutely unpredictable.

Final Solution

So from the moment I joined the company I started looking for a solution. I went through all my books on Agile and Scrum, searched on the Internet but didn't find any reasonable solution. But one day we decided to take a new approach. If unplanned work comes to the sprint and this work is big enough then we drop a low priority user story of equal size from the sprint backlog. If unplanned work is less than a day we count it as part of our 40% "unproductive" time and keep all previously selected stories.

The described approach works well, most of our sprints are successful now and we meet our sprint goals most of the time. I'm sure there are a number of companies and teams that have the same type of problem and I think sharing this experience will help them to create a more productive environment.

agile adoption ,agile application delivery ,agile approach ,agile estimation ,scrum ,scrum management

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}