How Writing Effective Jira Tickets Can Streamline Web Development

How Writing Effective Tickets Can Improve Your Web Development

Haruki Murakami once wrote that “without focus you can’t accomplish anything.” In any creative field, he wrote, focus and endurance are both vital to producing great work.

Maintaining focus and organization, especially in web development where we often find ourselves collaborating with you, our client, is important to keeping the project aligned with the project’s goals and established timeline.

This is why our team uses the Atlassian system, Jira, to manage projects. Jira enables continuing communication throughout the project while keeping the current status of tasks always in view. We also avoid a long scoping phase and begin development quickly, circumventing problems with communication or unaddressed issues in the future.

Jira is simple to use, but the trick is to write tickets that clarify the exact amount of information the developer needs to make adjustments. Technical Project Managers act as the conduit between the client input and our developers. During a project, a project manager will typically be the one who writes tickets in Jira, and by following these simple tips are able to effectively communicate your requests to our development team.

How to Write Effective Tickets

Whenever our developers review their tasks in Jira they look for details; the key is to include the right amount of details without overloading the ticket with excess information. The main purpose of tickets in Jira is to communicate with developers, and good communication minimizes project time, prevents confusion, and are a great reference source during the review phase.

What Should Be on the Ticket

  1. Title: This is a high-level overview of the ticket. The issue should be described here, written as the page that needs attention, followed by the necessary tasks. For example, “Home > Slideshow > Layout Broken on IE”

    jira tickets

  2. Description: This goes in the body of the ticket and is visible after it has been clicked on. It is a short description of the necessary task or observed issue, written as concisely as possible. We recommend using JIRA’s formatting tools, like bulleted points, to organize the information.
  3. Type: This describes the functional impact of the issue and can be a determinant of what kind of priority it should be. These are three of the most common types:
    • software bug - A bug affects the functional elements of the website, like a system error preventing a user from being able to complete their checkout.
    • improvement - An improvement isn’t a preventative issue, but perhaps something stylistic you’d like to change, like your website’s font.
    • new feature - A new feature is something that you may decide you want to add to your website as you watch it come together, like an email marketing form integration.
  4. Priority: This conveys how quickly the ticket should be addressed. These are the five different levels of priorities:
    • A blocker priority is an emergency, “all hands on deck” issue. It indicates an issue that makes the website non-functional, like web pages being inaccessible or users being incapable of logging in.
    • critical priority indicates tasks that should be top priority, but that don’t need to be addressed immediately as a blocker priority would need to be.
    • A major priority is the default for incoming tickets. It is less urgent than a critical priority, but should still be addressed immediately.
    • A minor priority is an issue that would be good to address at some point in the project’s development.
    • A trivial priority is something that has caught your eye that you’d like to address in the future.
  5. Status: Whenever making changes to the ticket, make sure that you update the status to keep it moving along the pipeline. For instance, if a developer moves a ticket to “Review” and you find issues that weren’t addressed in the original ticket description, change the status of the project back to “In-Progress” to communicate to the developer that there are changes that need to be made before the task is marked as “Done.”

    jira sprint example

  6. Other Helpful Things to Include: Including additional technical details such as specific URLs, which browser version you used, the device you used (phone or tablet), screenshots marked to point out problems, or links to other tickets will give the developer more of a context for how they should address the issue.

Note: If you decide you want something addressed that isn’t listed in a ticket, create a new ticket instead of adding the requesting the new task in the comments section of the old ticket. This will limit confusion and make the task easier to track.

Points to Avoid When Writing Tickets

  1. Avoid Writing Ticket Blobs: Avoid writing large amounts of text in the ticket description or in the succeeding comments. Large amounts of excess text will bury the technical specifics developers look for, making essential details harder to find.
  2. Keep Perspective with Priorities: Try to use emergency priorities like blocker or critical sparingly, that way our developers can have an accurate perspective on exactly what problem requires the most immediate attention.
  3. Focus on the Task: If you see an aspect of your website that you don’t like, writing “this looks bad” in the ticket isn’t specific enough. Keep the ticket content focused on specific commands to help communicate to our developers how you’d like the issue to be changed.

We’re here to help. Our web developers are a focused group of experts who take pride in what they create, and work hard to produce exactly what you need - nothing less.

Communicating what you need, in an effective, organized way will help with the progression of your development.

We're here to help you love your website! Don't forget to subscribe below for the latest helpful insights from our team to yours.