Wanna know how we distribute support tickets between developers / scrum teams? I’ll first describe an approach that didn’t work, followed by one that works for us (and Immobilienscout24, because we totally copied it from them). Before Scrum, the support guys at my workplace approached individual developers directly with third level support tickets. But with Scrum you want to disturb developers as little as possible and maximize the time spend on implementing stories. That’s why the support switched to posting tickets to a dedicated wall when we started out with Scrum a year ago.
- The wall had 20 slots for tickets, prioritized from left to right
- Each ticket had a “solve by”-date on it
- Developers were supposed to pick up tickets they could fix
- Each team set aside 20% time per sprint for “unplanned” activities such as support
This solution worked in the beginning but quickly broke down. In the end, our support staff and customers were frustrated with long response time. The developers were frustrated with an neverending string of tickets and the impression that very few people picked tickets. In hindsight our first approach was doomed, because it failed to answer 1 of the 3 critical questions (Who does What until When?): We never specified who was responsible for a ticket. Each problem can be solved by at least 2 developers and as these people belong to different teams it was tempting to leave tickets to someone else when time was tight in the sprint.
In November 2010 we attended the Scrum Day in Berlin and got to know how the teams at Immobilienscout24 handle support. Unfortunately I couldn’t find a page where they explain the method themselves. So here’s how we organized third level support for the last 4 months. It might not be exactly as the original but should be pretty close:
- Instead of 20 slots across teams, there are now 3 slots for each of the 5 teams
The 5×3 slots – only one ticket hanging - As soon as a support person posts a ticket into a team’s slot, the team has 24h to solve the ticket
- If they can’t solve the ticket themselves, they have to give it to a team that can
- The new team is also allowed to pass the ticket on, if they can’t solve it, but the third team must not
- If they can’t solve it either, the ticket escalates
- All this passing has to happen inside the 24h window
- The team that solves a ticket, returns the ticket with its name on it. This way the support guys learn what type of problems each team can fix and post the tickets accordingly
- The perk for developers: The 24h serve not only as a deadline to the ticket but also as a blocking time for the slot: After posting a ticket in a slot, you may only post another ticket in said slot after at least 24h have passed.
In an ideal world, each team has no more than 3 tickets per day.
In reality about 20%-30% of the tickets are passed on. That’s why the scrum masters look for teams that solve more than 5 tickets per day. If that happens regularly, something is rotten and must be fixed. This works well for us and certainly much better than the first solution: the developers aren’t overshadowed by a mountain of unsolved tickets, we help our customers much faster and our support guys don’t get shouted at and don’t need to be cross with the devs. Less conflict, happier people – 3-way win 🙂
(This post was first published on May 15, 2011 in my old blog.)