One of the many questions I get as an agile coach is “How to handle unplanned work in Sprints”. I really like this question coming from scrum teams. In an earlier post, I gave advice to the PO on how to create more insight into the Product Backlog. However, unplanned work is not always easy to handle and is an effort of the whole scrum team. Our DevOps teams are apparently struggling between working on innovation vs. operations and the outcome of Scrum to be more predictable.
“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk”
Starting teams, especially DevOps teams, start their scrum journey with more unplanned work than planned work in the sprint. all this unplanned work keeps them from having the focus on the sprint and committing to the sprint goal. Scrum teams need to minimize the amount of unplanned work in order to become more predictable.
What kind of unplanned work are we talking about? Based on my experience, there are two major topics for unplanned work. I will discuss them and provide possible solutions for the question: how to handle unplanned work in sprints.
The first topic of unplanned work is the walk-in of different teams asking for help or just stopping by for a chat. The first reaction of the team is that this is all necessary because they cannot not help colleagues when they have a question. The second reaction is that they need to have walk-in hours in order not to get distracted. The scrum master then can be the hero or the guard and escort everybody out of the team room who wants to interrupt the team outside the question opening hours. This, of course, helps the team to focus on getting things done but is not a sustainable behavior for the whole system. This behavior creates more distance with other teams and does not contribute to the cooperation between teams.
To avoid being isolated and have a bad reputation, I advise teams to gather as much information as possible. Team members can note down all the times they have been distracted, note down the questions they have had and the time (and the effect) they needed to help the colleague of other teams. Finally, the team then needs to analyze the data and look for common causes within the questions. They then need to find ways to handle these questions more effectively or find ways for the other teams to find the answers by themselves or that they don’t have to ask the questions anymore.
Within a DevOps team resolving operational issues always comes first. However, if we look for operational issues, we can find tons of them and they can fill our backlog for months. As we also want to be working on innovation, we don’t want to spend a lot of time on fixing operational issues. One way to find the balance is to have a priority lane on top of the sprint backlog. This means that everything that has a high priority (systems are down, agents cannot work on the system anymore, customers cannot login etc.) have to be fixed immediately. The items then get in the priority lane and everybody in the team will work on it to resolve the high priority incident. The problem here is that is not solving the incident usually, but examining the cause and managing the environment which takes up a lot of time. because teams don’t know how much time it will take, it is hard to be predictable.
To overcome this uncertainty, a certain timebox can be used for handling items in the priority lane. again, it is important to be transparent on the work which has been done in this lane and therefore keeping the PO up to date on the amount of time remaining. if more time is needed, then the PO has to be updated so that he then can manage the expectations to the stakeholders. Also, inspecting the amount of time reserved for this lane is something that team has to do frequently in the retrospectives in order to minimize the amount of unplanned work and be more predictable.
I hope this post helps you to become more predictable. I would also like to hear which patterns you see in your teams in their journey to overcome unplanned work and to become more predictable.