Skip to main content

Jira Technical Task Template

We currently have no firm standard on what needs to be included on purely technical tasks. We have a need to try standardize these as ticket definitions can be used historically to understand how and why a feature or fix was developed.

The ultimate goal when writing Jira tickets is to include the right level of detail without overloading the ticket with excess information.

The top reasons why it's important to write thoughtful, carefully constructed tickets are to:

  • Minimize the time it takes to fully understand the requirements.
  • Give enough information to the assignee to effectively tackle the feature/fix.
  • Not overwhelm the assignee with too much, non-essential information.

For our templates, we’ve settled on the following sections.

  • Short Summary: a brief at-a-glance description of the feature/fix.
  • Root Cause Analysis (bugs only): Technical investigation of root cause.
  • Technical Notes: Useful info for other developers such as queries, requests, responses, documenation.
  • Acceptance Criteria (Given, When, Then)
  • Resources: Slack conversations, emails or general information pertaining to the feature/fix.

These sections are concise enough to keep the ticket creation process light, yet comprehensive enough to scale for big items. Care was taken to not duplicate information that is already tracked by Jira itself, for example, the ticket creation date. Please avoid requiring redundant or tedious information in the templates.

Acceptance Criteria​

Acceptance criteria should be a true/false statement or even a checklist.

Describing complexities of a design, or even figuring out how to approach describing them can be a struggle. The answer can be reducing them to the simplest type of sentence: true/false statements. Either an element is there or it isn’t. Something behaves in a specific manner or it doesn’t. The information is correct, or it isn’t.

This structure is direct and simple. It allows for easier understanding of a feature by developers and, in particular, provides a clear guide to QA to craft test scripts.

Let’s take a look at how we might describe a table row in acceptence criteria:

  • When an order is placed, a row is added in the table.
  • The row should contain:
    • The first and last initial of the user who placed the order
    • The name of the user who placed the order
    • The date the order was placed (MM, DD, YYYY format)
    • The date the order was shipped (MM, DD, YYYY format)
    • The data points in the table should accurately reflect the shipping information stored in the database.
    • The data in the table should update when the database information is updated.
    • Is the item in the table? Yes.
  • Does it match the information in the database? Yes.
  • Does it update when the database is updated? Yes.