Using a ticketing system like Jira or Trello tends to be treated like eating your vegetables. Most software teams agree it’s important. But it’s not very convenient, it kind of gets in the way, and we’re probably doing it good enough so why are you making a big deal about it?

This is a tragic viewpoint. Most of the pains we experience in large teams and large organizations can be mitigated by getting better at using our ticketing system. The most effective teams observe two common rules:

  1. Tickets are an agreement between you and the boss/team about what work you will do. No exceptions.
  2. Tickets are free.

For those in the back who think tickets are a waste of time, point number one is the most important. Tickets are a way of protecting your time and energy. If all work is ticketed, you can’t be given secret work to do. You can negotiate for what you need to work on and what you can avoid. It becomes clear when someone has too much work to do. Ticketing protects the team. Boss wants something done but isn’t willing to make a ticket? Too bad. Not doing it. Boss wants to interrupt everyone for status reports? Go look at the tickets and leave us alone. Going overboard in ticketing minutaie is possible, but most teams are nowhere close to doing this.

The mindset of “tickets are free” means that creating, editing, and deleting tickets needs to be easy. If every ticket needs twelve fields filled out related to four different epics, and they need estimates and blah blah blah, the team will abandon the system. If a new task comes up that’s worth being interrupted for and creating a ticket takes more than a minute, the ticketing system will be abandoned.

Other ways that ticketing systems fall apart:

  1. Big Backlogs. The idea that “we’ll eventually get to all this” is a fairy tale. Grooming your backlog is usually a complete waste of time. If it’s important, do it now. Keeping a backlog of feature ideas is fine, but spending a lot of time keeping a big backlog well maintained is time better spent writing software.

  2. Long Lived Tickets. A ticket should only be worked on for a short time. Some teams treat tickets as a sacred novel that can’t be edited or changed. These tickets live forever.

  3. Vague Tickets. If the boss asks if the ticket is done and the developer is not sure, you have a ticket that is too vague. The ticket needs clarity as to what it means to be done. “Implement tests” is not a complete ticket. “Update command line parameters to include flag for ‘X’” is something that can be done or not done. Be specific.

  4. Thinking We Have to Write All the Tickets Before We Can Do Anything. Nothing leads to paralysis quite like thinking you need to know everything in advance. It’s beneficial to scope out as much as you reasonably can, but things can and will change as projects go on, and your ticketing system should support that.

In a healthy system you’ll find yourself making and moving tickets often throughout the day. Adding little notes to them about their status should become second nature. Linking to commits/discussions, etc, should become part of the workday. Dedicated time to cleaning up tickets should be rare. If you do this to manage your ticketing system… you might start to like it.