Interruptions and Missed Commitments

Drop of water - Interruptions have repercussions and possibly cause teams to miss commitments
Photo by NON on Unsplash

Some Scrum Teams find it difficult to stick to the commitments they make. While it can be for many reasons, a common one is that a team is being interrupted with urgent tasks that take attention away from the work that they planned.

What are some of the tools we can use as Scrum Masters to confirm that interruptions are really a problem for our teams, and to help them adjust to a more predictable way of working? Here are three tools that I’ve used with some success:

1. Make the “interruption” work highly visible to the team, and also to those who are doing the interrupting. 

Making things visible is usually a good idea in general. Going on the idea that interruptions potentially cause a slowdown or drag in the pace of work that was planned, making it easy to notice the interruptions can help people to notice the resulting drag. When everyone can see the drag, we can have more productive conversations, and consider course corrections that might help. 

During a sprint, I might use different colored cards on the Scrum Board to make additional work or scope changes more prominent. At the end of a Sprint, I might show a report during Sprint Review, showing what the Scrum Team actually worked on that was different from what they originally committed to. Most tracking tools can generate reports when stories are added to sprints after Sprint Planning, for example.  

It sounds easy, right? In fact, tracking interruption work can be very easy. The difficulty usually comes in with the discussions that need to happen. In order to get to a place where the team can work more productively, we need to attend to the needs of the people who are causing the interruptions.

One thing that can get in the way of the needed discussions is a team’s own awareness and fear that, by calling attention to the extra interruption work they are doing, they will solicit disapproval. People who feed the team extra work are often powerful and influential. It’s hard to say “no” to a favor from your boss. Being sensitive to this, as a Scrum Master, you might ask the team itself for ideas about what might help in their unique situation. You might work towards better connections and relationships between the team’s Product Owner and adjacent stakeholders. Through conversations, everyone may come to better understandings and agreements about how best to interact with the team, and get the urgent interruption work done without adversely affecting the planned work. This brings me to the second tool.

2. Coach the team in application of the Scrum Values (Commitment, Courage, Focus, Openness, Respect). 

The Scrum Values are always a handy tool. A Scrum Master can help to build an environment of trust by teaching these values. That awareness of the values, and the trust that is built, goes a long way towards resolving problems related to work interruptions.

  • Clearly, Commitment applies here. The Scrum Team has made a commitment at Sprint Planning, and the goals of the Scrum Team may be at risk whenever new work is inserted into the Sprint.
  • With Courage, the Scrum Team members will be able to speak up and escalate when interruptions cause a loss of Focus on their goals. It may take some intervention on the part of the Scrum Master to ensure that the message that the team should not be interrupted gets to the people who need to hear it.
  • The team should be able to display Openness with stakeholders and also with themselves about the challenges of the work. This may happen through ongoing transparent reporting. A conversation could be triggered at a retrospective. A Sprint Review may not be the place to go into a deep dive about why work was not completed, but it can be a place to bring to light some of the challenges that otherwise would be hidden. Once noted, other actions may be initiated.
  • Respect (the idea that the team members are all capable and independent) is always essential. On a team that lacked maturity, I overhead one team member disparage their teammates for being “lazy” and not completing tasks soon enough. What was overlooked was that those team members had been asked to do side work for another initiative for their manager. In this case, respect (of the goals of the Scrum Team) was lacking from the organization, and also within the team.  

3. Coach the team to understand its velocity and to make the most realistic commitments possible. 

Finally, once the “interrupt” work is visible, and we have done all we can to apply the Scrum Values, we should turn our attention to the reality of how much work the team has proven it can complete in a sprint (the velocity). 

Even if the interruptions are not formalized as user stories and brought into sprints, it may be possible to quantify and predict the rate of interruptions. Knowing this as a range will help the team to be more accurate when planning new sprints. If we know, for example, that we have a “drag” rate of about 30-40 hrs of team time per sprint, then we could reserve that time as a buffer during planning. By committing to fewer planned stories during a sprint, there will be a greater chance that the stories we do take on will be completed. We may even come to a place where we can set a service level agreement and communicate that out to other people and teams who make unpredictable requests of us. For example, we may be able to communicate out a lead time for new requests. It may be acceptable to the requestor and everyone may realize that what is being asked is not as urgent as originally thought.

None of this is easy, but those are some of the things I have tried. Please let me know how you have helped your Scrum teams who may be struggling with interruptions that cause them to lose focus from their Sprint Goal. Call me at (407) 223-9964 or show up at one of the Agile Orlando Meetups.

Scrum Master Service to Product Owners – A Discussion Focusing on Value

Product Owners have a hectic existence. They’re called upon to make important decisions constantly. The world is swarming with ideas and opportunities competing for attention. One of the favorite parts of my job as a Scrum Master is working with Product Owners. When I can help my Product Owner to find a focus that leads to our team delivering better things, I know that I am delivering good value as a Scrum Master.

School of koi fish - Product Owners have a hectic existence
Photo by Quang Nguyen Vinh from Pexels

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” This is a quote from The Scrum Guide. Maximizing value is a big responsibility, and it is all on the Product Owner to lead this.

Notice that I said “to lead this”, and not “to do this”.

The Product Owner needs to be able to express the results of their very important decision making around the product, but then they need to leave it up to the development team to work out the details of implementation.

The whole Scrum team needs to understand the big picture product vision, so they can work on things meaningfully. I’ve worked with Scrum Teams where the Product Owner took too much responsibility for details of implementation, and fed the development team what were essentially tasks disguised as user stories. Imagine the value that was lost to the organization due underutilizing the intelligence and creativity of every member of the development team!

As a Scrum Master, I have an outsider perspective. When I notice a Product Owner is distracted from focusing on value, I talk with them to try to steer them back on track.

One Product Owner I worked with had a Business Analyst background and was so interested in well crafted stories that they lost sight of the larger context of what we needed to deliver. Over a period of time, through discussions, I opened the way for them to see that the value is not in the stories, but in the work that makes it into production, and is actually put to use. It’s not easy to get out of a comfort zone, and this former BA struggled with letting go of details.

I encouraged them to write “shell” stories, and to involve the team more in discussions around the shells. The results of the team discussions could be formalized later by entering them into the story tracking tool. The important activity is the discussion and mutual understanding. The team should understand why we are doing something. The Product Owner should be able to explain that to a development team. The fastest and best way to do that is from talking to them about it, not by writing a detailed spec.

“Scrum Master service to the Product Owner … Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible … Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

The Scrum Guide

As a Scrum Master, I talk to my Product Owners about all aspects of getting the best value from our team.

We talk about value streams. How do stories come in to the team? How are they transformed into user value?

We talk about end users. Who are the people who will consume this product? How do they use our product now? Can we anticipate other uses? Can we imagine them in the act of using our product? Have we observed them using it? Can we categorize our users into broad archetypes or personas?

We talk about metrics. I always question the metrics that are already in place. Does looking at these numbers affect the value delivered to the end user? How? If we are looking at quality metrics, then how important is that aspect of quality to our users? Is there a more direct way to ferret out the thing that will bring more business in? Does this metric that we are tracking actually mask something that is more valuable to the user and therefore potentially much more valuable to the organization?

There is always a lot to talk about. And there are always a lot of decisions to be made when you are a Product Owner. It’s my job as a Scrum Master to assist you with better ways to manage the product backlog, so that the value is very clear to everyone who is working on the product, and it is delivered to the user in its highest fidelity form.

Single koi fish - Product Owners are more effective when they can focus on value
Photo by Madison Inouye from Pexels

Call me when you need a Scrum Master / agile coach who’s attentive to a Product Owner’s need to focus on value. (407) 223-9964