JIRA has made project life a lot easier in a lot of ways, but it has also introduced another set of issues focused on standardization. While all our project teams at Pixo use JIRA, that use varies in both good and bad ways.
It’s great that JIRA allows us to individualize each project based on specific needs, but we also need consistent practices across the (literal) board in order to use the project-tracking tool more efficiently. As a QA specialist who has to work on a variety of projects at a variety of stages, I’m using JIRA all the time, so consistent practices are essential.
It starts with the ticket. Specifically, what makes a good one.
Before we make any broad claims about defining JIRA ticket-making practices, let’s start with describing what we know shouldn’t be in a JIRA ticket. We don’t want tickets to be confusing, irrelevant, or too long, so that must mean we do want them to be clear, specific, and concise. It only seems fitting that we would want the guidelines surrounding these ideal JIRA tickets to have the same characteristics.