You either love it or hate it. Feelings towards the Attlasian flagship product are never neutral.

It's your biggest asset

The Jira ticket is not meant to limit you. The properly prepared task gives you:

Clear criteria on who is the addressee of the task
What does the owner wants to achieve
Why this is needed
And what are the acceptance criteria

Who/What/Why gives you a background on the purpose of your work. Your not just a cog in the machine, but you know what value are you going to deliver.

The Acceptance Criteria gives you the peace of mind on what are the deliverables and you don't need to worry and think about it.

Having all this knowledge you can focus on your work.

It speeds up the delivery

If the reporter did its job well, you have all the informations needed. Once the task is picked for an execution we can assume that we can eliminate:

Kickoff meeting
Additional questions at the beginning
Ambiguities

You don't waste extra time on your status or in dedicated meetings. You make less noise in common channels or in DMs. Scope of the work is clear.

You will probably need to ask a few things during the realization, because why not, but you don't start your work from asking yourself "What should I do? What does it even mean?".

It has the historical value

Staff always rotates. After a year no one really knows who ordered some feature, for what reason and what was the purpose.

Having the Jira ticket you can always go back and pull out that information. See the participants, reporters and assignees. Investigating the Discussion section could bring additional value.

Photo by Museums Victoria on Unsplash

Maybe there are some Pull (Merge) Requests attached? That's great! You can expand your knowledge and reach additional people.

It's often a common practise to mention the Jira ID in the commit message, so you can track the Jira ticket starting from the codebase if you're doing some reverse engineering.

You're a manager? That's perfect!

Creating a Jira ticket is blazingly fast - assuming that you know what you want.

For the template I always use the same schema - it doens't matter if it's Jira or the GitHub issue:

User Story:

As "<Role>"

I want "<what you want to achieve>"

So "<why this is important>"

Acceptance Criteria:

<deliverable>

<deliverable>

<deliverable>

Background (optional):

<What's the story behind it or why this is needed in details. Some links to documentation, external services and so on>

Creating a ticket takes in average about a minute to three. You can always come back and change some points or details. Nothing is written in stone.

The people you're working with will be grateful for this and you will have more time to deal with more important matters.

Your time is your asset, don't waste it.

The Power of Jira ticket

Comments

Ways of Working

A Good Agent Skill Is a Contract, Not a Prompt

More from this blog

Stop Using Full OAuth Handshakes for Internal Microservice Auth

MCP vs ACP: Clarifying the Protocol Layer in the Agentic Era

A Good Agent Skill Is a Contract, Not a Prompt

Stop Writing Bigger Prompts. Start Designing Agent Skills.

Small Pull Requests Win Every Time

It's your biggest asset

It speeds up the delivery

It has the historical value

You're a manager? That's perfect!

Command Palette

Comments

Ways of Working

A Good Agent Skill Is a Contract, Not a Prompt

More from this blog

It's your biggest asset

It speeds up the delivery

It has the historical value

You're a manager? That's perfect!