Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

What's the best way to determine IT ticket difficulty

We had a non-IT vendor come in and show us their ticket statistics and one of their metrics was ticket difficulty. My initial thought is to set a baseline difficulty on each component and have it increment based on time spent open. The field would be manually editable also. Does this sound like a good idea, or has someone done this already? Not looking to add much to our workflow.  

1 answer

0 votes
Walter Buggenhout _ACA IT_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Mar 25, 2023

Hi @Jared Holliday,

If you want to introduce something like this, it will always be a pretty subjective metric. What is difficult for me may very well be a walk in the park for you or vice versa. Before you try to introduce a metric like that, ask yourself how it would help you get things done more effectively.

In one of the software teams I used to work in, we had a habit to categorise bugs as simple or more complex. This qualification was made by the team member who read the bug report just based on gut feeling (and common sense). All we used it for, was to apply a generic estimate to it so it became feasible to add a manageable number of bug fixes in sprint planning.

My advise would be definitely not to over-engineer something like this. At worst, just add a custom field where your agents can indicate if they think it's easy or not. And use metrics like time tracking of ticket lead time to see if seemingly easy tickets are indeed fixed faster than difficult ones. But for prioritising tickets, rather use your SLA's, impact and urgency or stuff like that.

Hope this helps! 

Suggest an answer

Log in or Sign up to answer
Site Admin
AUG Leaders

Atlassian Community Events