ScrumMaster Advice: Learn when to say “No”

Nov-21-2007

Post written by Chris Spagnuolo. Follow Chris on Twitter Add comment

One of the key tenets of Scrum is the team’s absolute, uninterrupted focus on the current sprint tasks. One of the key responsibilities of the ScrumMaster is to ensure this focus and to fend off unnecessary interruptions. It sounds easier than it is. As a ScrumMaster, I have had the distinction of experiencing first hand the difficulty of defending our team’s focus during a sprint.

Case in point: Our team was working on a very focused and successful sprint when we were approached by a former colleague. He wanted us to begin working on an internal development project immediately and stressed that it was of ultimate importance to the organization. We would need to cancel our current sprint to accommodate his request. After a bit of probing about the “importance” of this project, it became very clear that this wasn’t as high of a priority as he thought it was. In addition, I had previous experiences with said colleague and knew that his tendency was to focus too much on relatively unimportant tasks.

After some deliberation, I made the decision as ScrumMaster to tell him that we would not be canceling our current sprint to work on his request. Instead, we would prioritize his request in our backlog and get to it in our next sprint. I assured him that the two developers that would work on his request would be 100% committed to his tasks during the two-week sprint. His tasks would receive the same uninterrupted focus as our present tasks were enjoying. After explaining this to him, he acquiesced and accepted a delayed start for his tasks.

We did indeed work on and complete his tasks during our next two-week iteration. In fact, when we were done with our sprint, he was surprised to find that all of his functional requests had been completed (of course, it was no surprise to our committed team). At the conclusion of our sprint we found out that his team was not ready to implement our new functionality. Neither the servers we needed nor the necessary software infrastructure was available to deploy the application. Nearly 3 months later, his non-agile team was finally ready to deploy our functionality. So, his high priority request really turned out to be very low priority in the end.

The moral of this little story is that ScrumMasters need to know when to say “No.” Sometimes, there may be a very valid reason to cancel your sprint to address very high priority requests. But, ScrumMasters need to use a lot of discretion and ensure the validity of these “high” priorities. It is extremely important not to interrupt your teams for just anything. In this case, had we interrupted our Sprint to fulfill this request, we would have shifted our focus from a highly productive Sprint to address a low priority need. In the end, we did the right thing by saying “No.” We completed our sprint very successfully and satisfied our paying client and our team remained focused and effective.