Creating effective Jira tickets

Like many engineering departments, VidMob engineering uses Jira tickets as a way to organize and track work. Regardless of what one thinks of Jira in particular, work tickets are a common and very useful tool that helps organizations get tasks done. There is no one perfect application or template for this kind of thing. However, I think there are some abstractions that can be pulled out that can help anyone and everyone make more effective tasks in whatever system they’re using. One should be able to answer these questions after reading the ticket:

• What’s a one-sentence-or-less description/summary of this task?
• Why does this task exist?
• What does it mean for this task to be done?
• How can one check that?
• What is the plan for doing the work, at least at a high level?
• How does this task fit into the big picture of what we’re doing?

We create an effective ticket by working backwards from the desired outcome. First write a clear statement of what it means for the task to be finished. Whether you use formal acceptance criteria, a looser ‘definition of done’, user story, or something else, the ticket needs an articulation of what it means for the task to be complete. One shouldn’t start work on a task without an understanding of when to stop. Thinking about the result also brings focus to the task, reducing scope creep and making it easier to see what things should be folded into the current task and what things need to be pulled out to separate ones.

Once it’s clear what it means for the ticket to be done the next step is adding a plan on how to verify that – defining this up front really reduces disruption. The intent here is that when the implementer thinks they might be done there are no barriers to checking that – they don’t have to figure out what pages to hit or buttons to click, they don’t need to track down an appropriate DB record, they don’t need to track down anyone else to verify that a value is correct and not just plausible, etc. Having this clearly stated in the task is also very helpful in figuring out which automated tests to write and how.

Next is a plan for how to actually do the work. This often blurs into the actual task implementation work, but the more guidance that can be provided up front the smoother it will be to execute. Sometimes this might  be very specific (e.g. change these lines in these files in this way), and other times it might be more general. Having a good implementation plan also helps in understanding the real complexity of the work, which in turn is vital when making estimates and thinking about risks. This is also a place where approaches can be raised and discussed much earlier than in code review (at which point making significant changes can be quite expensive).

With those three pieces in place there should be minimal dependencies on other folks during implementation since foreseeable questions should be answered, the approach outlined in the implementation plan can be reviewed and discussed before the implementer gets too deep in the code (e.g. during sprint planning), and the path has been smoothed for execution and release. Now it needs a bit of context around the task. This serves several purposes. It’s important for all of us to feel that the work that we do matters – few things burn someone out faster than feeling that the work they’re doing is pointless. Beyond that, an understanding of the bigger picture helps whoever is working on the task make decisions during implementation – e.g. having an idea of how quickly use of a system might scale could lead to different approaches to implementation. Finally, create (or re-visit) the title / summary for the ticket to make sure it’s a good, clear indication of what this work is about.

Not every ticket needs to be a work of art, but keeping these principles in mind even for relatively abbreviated tickets will set people up for success.