If you work with a big company, chances are you’ll have to deal with a ticket tracking system. They’ve become a critical part of IT helpdesk operations, of scrum and agile teams, of collaborating with remote teams, and pretty much everything. But tickets can lead to development paralysis, especially when they’re used to drive a Scrum/Agile team – so let’s talk about ways to deal with ticket overload.

A good ticket system can be an asset for managers and developers alike. Managers like ticket systems because they provide great reporting and supervision tools for a big development project. Developers like checklists, they like having lots of ideas floating around, and many of us really prefer receiving tickets via email rather than phonecalls from users requesting development work.

But sooner or later, most developers wind up feeling like Kirk here, drowning in tickets and ticket management work. Why is that?

Captain Kirk deals with tickets - I mean tribbles.

Ticket systems introduce a number of competing pressures on your development staff. Your users learn rapidly that they need to submit tickets if their ideas or needs are to be heard. The more tickets you submit, the more influence you can have on the development process.

Your managers learn to build reports on ticket backlogs, estimate accuracy, close rates, and so on. By filtering tickets and handing out task lists, they gain an easy way to supervise the programming team. And developers often get the short end of the stick: a backlog of thousands of tasks, constant progress reports, and little freedom to pick and choose their work.

Naturally, a program designed “by ticket” can wind up a Frankenstein creature. And the biggest kicker is that all of this stuff happens naturally, without any effort on your part. Tickets make managing developers seem so easy – so let’s look at the problems that can crop up in your ticket backlog.

  • Anyone can write a ticket. This is a blessing and a curse. Every single person in your organization has valid, useful ideas and they deserve to be heard; but it’s easy for someone to write a ticket with no detail, or a ticket request that contradicts your system’s design principles. It’s also easy to get IT tickets or operational tickets that aren’t about software development at all!
  • Tickets often include suggested resolutions, which may not be the right ones. A common mistake when writing tickets is to detail what feature a user wants, not what problem you want to solve. An end user might write, “I need a button here to send the report via email,” but what’s really needed may be an approval workflow or a daily notification list.
  • Clever users can scheme the system. Many years ago, one user I knew took advantage of a policy that increased priority for bugs. He rewrote all his feature requests as “Bug – Steps to reproduce: Go to form X. Expected result: There should be a button to do Y. Actual result: No button exists.” In general, if your users are crying out like this for more features, maybe it’s a sign for the business to invest more in software development!
  • A large backlog discourages proper maintenance. When your users have a thousand requests in the queue, your manager is going to demand justification when you want to do something not in that list. It’s not always obvious to management why there are 500 tickets that can’t move forward, when the programmers really want to redevelop a badly malfunctioning queuing system.
  • Tickets aren’t prioritized in development order. Your managers don’t understand the architecture of the code. They look at the business value of the ticket, the title of the person who wrote the ticket, and maybe the expected development hours. Instead, as a developer, you should focus on finding a bundle of related tickets in the system that you can execute all at once.
  • Ticket metrics are easy to generate. Because tickets are generally managed in a central database, any manager can write a few reports and put together a presentation on the development team’s progress. And since these metrics are so easy to see, when you make a mistake categorizing a ticket, you’ll be explaining to a manager why your metrics look wrong.
  • Metrics can, and will, be gamed. If management indicates that a particular statistic matters, the team can find ways to optimize that one statistic. Without a broad view of the business, a mischievous team member can show progress in one metric when the project is actually falling behind.
  • Ticket estimates often don’t include time to research the problem. Your senior people usually get the toughest tickets, or the ones that don’t make sense. Often it will take them lots of time to just set up a test, or interview all the people involved, in order to figure out what the real problem is, and that time doesn’t show up well on ticket management metrics.
  • Architecture improvements are hard to compare against user requests. This one is just fundamental. When a user of your system says “It’ll save me ten minutes a day if you rewrite this dialog box,” your manager knows exactly how much that task will benefit the company. Can you guess how much time you’d save by writing a scripting language for tests? Probably not.

So is it hopeless? Not really. Most of the problems with tickets can be addressed if you approach them with a healthy skepticism. The fact is this: a ticket can be changed. If you can keep your ticket process fluid, if you can maintain some freedom you can find ways to use tickets for good.

Ticket Taming Techniques

Start off by having – or selecting – a visionary who has the role of an architect or team lead. This person has the job of saying “no” to some requests and helping to develop others into useful tasks. There was a great dilbert cartoon that is unfortunately lost to the mists of the pre-Internet age, where Dilbert illustrated that the difference between a company with a strategy and a company without one was the ability to say no. Learn to say no to some ideas.

The architect should look at each ticket as it arrives, weigh its value and difficulty, and help get rid of tickets that aren’t likely to have a positive effect overall. If the architect knows that component X is going to be redesigned soon, the architect should put on hold all tickets related to that component until the rewrite is complete. If the architect sees a bunch of overlapping tickets, he or she needs the authority to consolidate them into a more focused feature.

Keep in mind that architects burn out if you keep them on the same project too long. If you don’t change architects regularly, you should! New eyeballs and a fresh perspective can often inject enthusiasm into a moribund project. If you haven’t tried it already, consider rotating your team leads yearly, and give each one an opportunity to eliminate the worst mistakes of their predecessor, as well as to add their own flair to a project.

Problem: The Ticket Treadmill

When your ticket backlog gets too great, your developers find themselves constantly rushed and stressed. They rush tickets out the door and the result is even more tickets. Yikes! How can you break the cycle?

The answer is to slow down the team. Instead of solving a task as fast as possible, reinterpret the ticket: what is the underlying problem that caused this ticket to go to you? Is there a better way to do this? Make sure your developers understand the problem thoroughly, then:

  • Schedule 15 minutes of time to update tickets at the end of the day. A developer who is constantly bouncing back and forth between their code and their ticket tracking system is probably too distracted to deliver really awesome software. Tell your team to focus on the work. Ticket maintenance should always be a valuable secondary activity. Let them know it is okay to put it off until the end of the day, but don’t let them skip doing it.
  • Resist the pressure to provide low time estimates. This is tough, since we all have a competitive instinct and we all like to show off how fast we can get things done. But our goal is to make the system better! Constantly rushing to try to match tight estimates can make even great developers churn out bad code. Be cautious and give yourself lots of leeway; that extra time makes it possible to…
  • Fix more than just the problem. If you get a lot of tickets for “adding an email link to this page,” develop a bigger solution that adds email links to all pages. If you get tickets that say “Remember the size of this window when I reopen it,” write a tool that remembers the size of all windows. If someone sends you lots of tickets to “Fix problem Y for file X,” develop a tool to identify and fix the problem, document it, and deliver it to the end users. Eliminate all tickets of that type, not just that one ticket.
  • Discuss tickets with your users in person. Or over screencasts. Take the time to talk to them when it’s not clear how to best solve a problem. You’ll be surprised how often something becomes obvious when you see the problem firsthand. And, if you need more experience, try walking a mile in your user’s shoes – ask them if you can try working their tasks for a few hours. Suddenly you may realize why they keep sending you problematic tickets.

Problem: Time Crisis

Sometimes you find that there isn’t enough time in the day to actually accomplish your work. This is common, but often represents a problem outside of your ticket system. Your ticket system has really good statistics, but there are no statistics for “time spent in meeting rooms.”

So how can you get your developers back to productive work?

  • Create “activity” tickets for time consuming activities. Do your developers have to spend 30 minutes per day preparing reports? Monitoring servers? Talking to customers? Every week or so, give your developers a ticket with a time estimate that indicates how much time you want them to spend on these activities. Tell the developer to bill time to this ticket rather than pretending that the time just vanished. Your managers need to know that this stuff is happening, since it affects everyone’s productivity.
  • Use the backlog to bring on board new developers. A junior developer can often surprise you by developing inventive solutions to age-old bugs other developers won’t touch.

Problem: Too Much Tracking

It’s easy to get overwhelmed with detail. When you have a ticket tracking system that works, managers can ask for lots of reports. They can ask for statistics to update daily. They can ask that each ticket be categorized in a dozen different ways.

A healthy ticket system doesn’t overwhelm team members with busywork, it should help the team by providing a framework to track and demonstrate their progress.

  • Ask your management which metrics matter. Don’t be shy! They want you to succeed just like you want to be seen succeeding. If they really care about meeting deadlines, focus on those statistics that will give them predictable deadlines. If they want to see the backlog decrease, focus on fixing lots of little tickets and de-duplicating tickets that refer to similar tasks. But bring them around to…
  • Encourage the broad view. If the team focuses too much on “tickets completed per sprint,” remind them that the application’s latency is improving, or the UI is getting better. Emphasize the reduced maintenance work spent by the IT team. Show everyone that ticket statistics are only one part of the whole.

After all, the real goal of a ticket system is to help make the great work you do visible to everyone. Don’t let your ticket system become counterproductive; be aware of its limitations and you can help drive it in a positive direction.