In one of his recent weekly email tips, Mike Cohn wrote about eliminating inefficiencies by making them visible.
Mike wrote about a scenario where a team was trying to work towards a goal, but made limited progress because their efforts were repeatedly diverted onto other work – such as client issues, emergency fixes, and so forth.
The solution he described for this type of situation is to make the interruptions visible so that you can measure their impact, understand the nature of the work, and then manage them.
The best approach is to eliminate these inefficiencies – but if you can’t prevent interruptions, it’s possible to at least plan for them.
If you go down the path of planning for the interruptions (adding a buffer to your iterations), then you’ll want to measure how the team is tracking against the allocated buffer.
I once worked with a team that was plagued by unplanned work – interruptions from other teams that were “urgent” and would only take a little bit of time… the “can you just help me with this” type of stuff.
To help make this work visible, we planned a block of “unplanned” time each iteration for each member of the team, then allocated them a number of “hourglass” tokens – each worth one hour of effort.
We set up a wall, the O.S! Wall, that had two columns – “Available” and “Used” – and a row for each team member. At the start of each iteration we put each person’s allocation of hours in the “Available” column.
“O.S!”, by the way, was officially known outside the team as an abbreviation for “Out of Scope”, and colloquially inside the team as “Oh, shit!” – as in “Oh, shit! We hadn’t planned for that!“.
As they responded to the ad hoc requests for work, team members recorded the time they spent by moving the hourglasses from the “Available” column into the “Used” column (an hourglass turned on its side was worth 30 minutes).
At the same time they completed an “O.S! card” that recorded, amongst other things, what the task was, who requested it, a high level category to describe it, how much time it took, and whether it had been approved if necessary by the Scrum Master or Product Owner.
The board gave a very clear visual indication as to how much of their unplanned time they’d spent through the sprint. The O.S! Cards allowed us understand the types of issues were coming up and how much time was spent. We punched the data into a spreadsheet each iteration to chart the trends over time.
The aggregae time data allowed us to predict how much buffer we needed to allow in each iteration. The details we captured on the O.S! cards allowed us to learn about the type, effort and frequency of interruptions the team experienced, and to plan techniques for eliminating these types of work in the future. For example, a high number of report requests could indicate the need for a a self-service reporting tool, or provision of some report writing training,
Being required to go through this process also helped train our team to be a bit more discerning when it came to assessing each unplanned task. Having a visible “O.S!” limit forced them to decide if a task was really as “drop everything” urgent as claimed, or whether it was something that could be pushed back on and planned as part of the regular iteration cycle.
If an individual ran out of hourglasses, then they could trade off planned work with someone who had spare hourglasses (if they were truly the ONLY person who could do the ad-hoc request).
If things got really bad and they just HAD to go in excess of their planned unplanned time, they could get permission to use limited number of “red” emergency O.S!. hours – but only after negotiating with the product owner / scrum master around the impact on the planned iteration.
The O.S! wall ended up being a really useful tool for visualising, tracking and managing these unplanned interruptions to the team.
If you have any tips on managing unplanned work, I’d love to hear them – please share in the comments!