Managing Support Tickets Alongside Feature Development

When your team’s engineers are responsible for both feature development and support tickets, it’s vital to surface that work in your sprint board. This is especially true for teams whose primary function is to build products and features and whose performance is measured on the delivery of those products and features. But support tickets don’t conform to the usual laws of software development. They require a different, utterly backwards approach if you want your team to continue to deliver and win. Time box those suckers.

The usual approach is to size a support ticket before including it in the team’s sprint. Then break it down into tasks like any other ticket.

This approach is a one-way ticket to development hell. By their very nature, most (not all) support tickets are practically impossible to estimate. That’s kind of how they became support tickets in the first place. No one knows how long the work is going to take until the discovery and debugging work has been done. And no one knows how long discovery and debugging, itself, will take (even if they say they DO know).

There is no escaping this empirical truth.

So how do you account for support ticket work in your sprint? Time box it, baby.

Flip the usual estimation → task breakdown workflow around for these support tickets. Start by first deciding as a team what percentage of your sprint you can dedicate to support tickets. Then, include tasks in each sprint for support tickets and assign them the appropriate size to represent how much time you’ve allocated for support tickets. This could be one task from one ticket, or a few from different tickets. Just make sure they add up to no more than the percentage of your sprint that you’ve allocated to support work.

You might be wondering how this eliminates sizing your support tickets. Here’s how that works:

Instead of estimating your support tickets and carrying them over from one sprint to the next, try this. Start with just the support tickets that are still in discovery/debugging phase.

1. Start with each of your support tickets that are still in discovery/debugging phase. Assign them your largest estimate ranking, whatever that is for your team or company. This is only for support tickets that are still in discovery/debugging phase.
2. Create some tasks for each of these support tickets and number the tasks starting at “1.” Title them something like “Discovery” or “Debug.” Here’s how many tasks to create: however many sprints are in a three-month period for your team or company. For example, if you have two-week sprints, you’ll create 24 tasks. (I know that sounds like a lot! But stick with me.) I use three months because that’s as long as any support ticket should ever take. If it’s taking longer, it warrants some escalation and broader discussion. Do not estimate or size these tasks yet. You’ll do that next.
3. During sprint planning, include tasks from each of these support tickets that you’ll work on in that sprint. This is why you numbered the tasks. You’re going to pull tasks in order. When the sprint ends you’ll mark those tasks as “done,” and if more debugging is necessary, you’ll use the next task in the numbered set of tasks. This way, when you look at a support ticket, you’ll be able to see instantly how many sprints you’ve already spent in discovery. If the next task in a support ticket is numbered “4,” you know you’ve spent three sprints on debugging so far.
4. Time to size. If you only have one support ticket your team is working on, then that task should be sized to represent the percentage of the sprint that you’ve allocated to support tickets. If you have three support tickets you’re working on, then you’ll have three different tasks and each task will represent 1/3 of the percentage of the sprint that you’ve dedicated to support ticket work. That’s why we wait until sprint planning to size the tasks.
5. At the end of the sprint, as long as someone has indeed worked on each support ticket task for the amount of time allocated, mark the each task done. It doesn’t matter what the outcome was. If a support ticket is not yet complete, pull the next task from that ticket into the next sprint and assign it the appropriate size.
6. If a support ticket has been debugged and a fix documented, mark ALL the remaining discovery/debugging tasks in that support ticket as “done” (or archive them, as you prefer). Since the solution is now understood and scoped, you can break it down and create new tasks the way you would for a feature—with one difference!
   You should break the ticket down into tasks that are the smallest size that you use for ticket sizing. If you would normally create a task that is medium-sized, break it down further. Even if it’s just to represent, say, 10% progress on that task. This way you can still limit support ticket work to your allocated percentage of your sprint.
   Add these tasks to your sprint along with tasks from support tickets that are currently in discovery. They should altogether add up the the total percentage of your sprint that you’ve allocated to support work.

I’ve found that engineers embrace this approach. It relieves a lot of pressure and prevents resentment. It’s pretty demoralizing to work on support tickets in what feels like your spare time only to be nagged about how long it’s taking. As product and engineering managers, it’s our job to help put procedures in place that protect our teams from this kind of impossible situation.

Support tickets usually can’t be estimated. Trying to estimate them is where the cycle of development hell begins. So don’t. Time box them.

Before you go… consider becoming a newsletter subscriber. You’ll get new product management insights each week.