Software development is like a lot of jobs, in that there’s some sort of system that lists the things you need to work on. Doctors and lawyers have appointments, technicians have calls, and software developers have tickets. It’s a fairly basic idea, open whatever ticket tracking software you use, find the stuff that’s assigned to you, do the work, move the ticket to the next step in the process when you’re done, rinse and repeat. That said, it’s still easy to create unnecessary problems for yourself just by getting lazy when working with tickets. So with that in mind, here’s a few “commandments” that will make the administrative part of your life easier.
I. Thou shalt keep thine tickets as up-to-date as possible, so that thoust can refer people to them when a status is requested
This is probably the easiest rule to forget (I regularly break it), but also the 1 that will help make your life easiest if you can follow it. It’s real simple, keep your tickets updated. Just make the time every day to do it. That way, any time someone asks for an update, you can just tell them that the latest status will always be on the ticket. This doesn’t mean that you have to constantly add comments to tickets for every tiny little thing, but any time the ticket’s state changes, at the end of the day (if you worked on it all day), or when you stop working on that ticket to move on to another. Eventually, if you keep telling people to check the ticket, along with those same people seeing regular updates on your tickets, you can get people to just check your tickets before they ask you about them. In other words, this 1 little habit can stop countless interruptions before they happen.
II. Thou shalt not change the state of someone else’s ticket
Just because someone doesn’t follow the first “commandment” doesn’t give you the right to take matters into your own hands. Don’t be going into the ticket management system and moving tickets around without getting the assignee’s explicit permission, and even then – they should do it themselves. Screwing with someone else’s ticket is a good way to create problems. Remember, the point of the ticketing system is to be the source of truth for the state of all work going on, as provided by the individual(s) who own that work at the moment. I’m sure I’m not the first developer who’s had really puzzling conversations with QA about testing tickets that weren’t actually done yet, or with PMs about whether a change that’s still being actively coded is going to get deployed today – all because someone misheard something during stand-up and tried to help by moving a ticket on the board…except the ticket wasn’t ready to move on. Just make everyone’s lives easier, and let the people who own the tickets move them through the workflow.
III. Thou shalt not start on a ticket that you know has open questions
In theory, you should never have a ticket land on your plate that still has open questions, but sometimes tickets don’t go through the normal grooming process (e.g. support tickets), or sometimes we get ahead of ourselves and skip steps. No matter the specifics, sometimes there’s a ticket that needs some information. Regardless of whether it’s a bug added mid-sprint, or a ticket that just needed clarification from another group that should have been in by now, if there’s information you’re going to need to do the work, don’t start the work. Starting a ticket knowing you’re missing information is a recipe for failure. Don’t set yourself up for that – ask for the more information, and leave your ticket in whatever “To Do” state your team has until it comes in.
IV. Thou shalt make and announce all decisions related to the ticket, on the ticket
Regardless of whether questions came up before you started working on a ticket, or after, every clarification needed, or decision made about the ticket should be recorded on the ticket. Ideally, everything should happen in the comments of the ticket, but even if you had a meeting to go over whatever questions or issues came up, it should still be summarized on the ticket. In short, the ticket itself should be the source of truth about the work that was to be done. Nobody should ever have to go to their Slack history, or get forwarded an email thread, or look anywhere else for all the details on what was required. Tickets are the contract for the work to be done (and contracts are important). Just because it’s not a formal document written by lawyers doesn’t mean it’s not what everyone agreed should be done, and the official, agreed-upon documentation of work to be done should not be missing relevant details. At a simpler, much more common level, memories aren’t infallible and putting everything in the ticket means always knowing where you can find important information.
V. Thou shalt not refer to tickets by number
Look, I get that the little ID is quicker to say than summarizing which ticket you’re working on, especially since odds are that same ID is showing up in all your commit messages. That ID value is very meaningful to the database, and I’m sure it has meaning for you. But outside of those 2 entities (only 1 of which is an actual human being), hearing “I worked on PROJ-123, and I’m going to wrap that up today and start on PROJ-124” is meaningless. Actually describe the work to be done so people understand what’s being discussed. “I finished writing up the unit tests for the configuration flag to perform a force delete so next up will be cleaning up the log spew we’ve noticed in QA.” See how much informative that second example was? If I really need to know the ticket number of the stuff you’re doing, I can just check the board later. The truth is, I rarely need the ticket number for other people’s work, at most I just need to know if it got merged into the develop branch so I can pull it in.
In software development, we do most of our work through development tickets. Making sure we adopt good habits around them makes our jobs much easier. The good news is, none of these “commandments” are particularly onerous. The bad news is, they’re pretty easy to forget. If you can make habits out of these, they’ll help you avoid a lot of unforced errors in terms of keeping track of everything.