When teams move to Scrum from a more chaotic development method, there is often a struggle with convincing the new Product Owner (or the business folks that they report to) that the team cannot be retargeted on a whim. A benefit of Scrum is that teams get to focus heads down on a set of functionality for the entire sprint.
What if a production bug comes up that cannot wait for the next release at the end of the sprint? What if something less important than a production bug comes up, but the product owner still sees it as an “easy fix” that would make an important stakeholder happy?
Should you allow diversionary tasks?
Scrum by the book says you should not allow this to derail the team, and I’m all for that, but often there has to be a balance when an item truly is critical.
Kanban teams handle this by having an “Expedited Lane” where the business can put a story that bypasses the normal process and takes precedence over anything else the team is working on. This is to be used sparingly, and under strict rules like a WIP limit of 1.
I’m coaching teams at a large internet company right now that struggled with a problem of lots of little requests eating away at the team. We handled it in two ways, and things seem to be moving really smoothly now and everyone’s happy (the team and the business).
Step 1) Make the little things visible
In the team’s first sprint, as they transitioned to Scrum, there were still lots of carry over items that had not been written as proper agile user stories with Scrum in mind. And lots of these were little “one off” requests. To make the impact of these visible, those items all went on red sticky notes on the board. The newer agile items that went through the proper process were on yellow sticky notes.
The goal was to make it clear how much the team was getting sidetracked, and this was obvious when half the board had red stickies at the end of the first sprint.
Step 2) A Scrum version of Kanban’s Expedite Lane
As the team and the business got used to Scrum, those red stickies decreased in number significantly and quickly. There are still issues though that truly would benefit the business if they could be addressed more quickly than the 2 week sprints allowed, and requests that are so small that they do not benefit from the agile planning process.
The team wanted to shut down most of these types of requests and say “add it to the backlog”, but they also wanted to stay flexible to the needs of the business. How could we create a process that allowed for that flexibility while discouraging the abuse of it?
The solution we used was to put two “red sticky” boxes on the team’s scrum board, in a corner and set aside from the rest of the scrum board stories. If the Product Owner wanted to give the team a red sticky request during the sprint, they were allowed to do that anytime, as long as they put the red sticky in one of the two boxes. Once there, the red sticky stayed there as a way to record what the request was, and that one of the two allotted spots had been used.
This simple method effectively created a WIP limit of 2 diversionary requests per sprint, and gives the business the flexibility they wanted. But the product owner also had to consider carefully before they used one of those spots, creating an incentive not to abuse the system (which is what the team wanted). It’s worked well enough that multiple teams at this client are now using it, and it’s unusual that both spots are actually used in a given sprint.
