Reimagining ‘work’ in Jira to better represent all teams

[#1]

As more teams make Jira their home for work, we’re committed to improving the language in our tools to better reflect the diverse ways you define and manage your work.

Today, we’re excited to announce the introduction of work as the new collective term for all items tracked in Jira. We’re also exploring ways to incorporate the language you use for your own unique work types.

The issue with ‘issues’

Jira was originally developed as a bug tracker, designed to manage ‘issues' – and for years, that’s how we’ve referred to the work teams track in our tools. But, as our products have evolved, so have the use cases they support.

Today, Jira serves a diverse array of teams, each with unique workflows. We believe that the true power of Jira lies in its flexibility to represent all kinds of work. We’ve heard from you that the term ‘issue’ can be limiting and somewhat confusing in the context of your work.

So, going forward, instead of referring to your work as ‘issues,' Jira will call the different items you track exactly what they are: work.

So, what’s changing exactly?

This update is more than just a simple find-and-replace. Through discussions with numerous teams, we've learned that you often have unique terminology for your work in Jira, and we want the tool to reflect this.

Just as today, you can still customize as many work types as you need to accommodate your team's language, workflows, fields, and automation preferences.

We’re extending that flexibility by making Jira smarter. Now, when you're working on a specific type of work, the interface will dynamically adjust to fit that context. For example, engineering teams see 'bugs' or 'stories,’ whereas Marketing teams may see 'launches' or 'copy.’ 

By aligning more closely with the work types you use, we aim to make Jira speak your language, whether you're a tech-savvy developer or a creative campaign manager.

When it's not possible to use your specific language or when we’re referring to various types of work collectively, we'll use the term work item.

We're continuing to explore ways to better integrate your language into Jira, and welcome any suggestions you may have.

How this impacts other languages supported by Jira

Our team conducted research to determine how best to implement these changes across the various markets supported by Jira and to assess whether updates to the language were necessary.

As a result, the following languages will have updated terminology to reflect this change: Chinese (Simplified), Chinese (Traditional), Dutch, Finnish, Japanese, Korean, Norwegian, Portuguese (Brazil), Spanish, Swedish and Turkish.

All other supported languages will retain their current terms.

The road to work in Jira

This update will be rolled out gradually, with work replacing ‘issue’ across all Jira Cloud products, including Jira Service Management and Jira Product Discovery, in early 2025. Updates in other products will follow soon after.

Apart from informing your teams, there's nothing you need to do in product to prepare for this update.

Given the scope of this change, there is a significant amount of material that needs updating. You may still encounter the term ‘issue’ in some of our experiences, documentation, and support materials as we work through these updates.

---

We welcome your feedback, comments and questions as we refine Jira's language to better align with the needs of all teams.

FAQs

Note: We'll keep updating this FAQ to address any recurring questions or concerns.

Q. Why not use terms like ‘item,’ ‘record,' or ‘activity’?

While these are all valid options, our research indicated they can be ambiguous in what they represent. Our goal is to make Jira the place of work for all teams, and we believe 'work item' is a natural replacement for ‘issue,' as it more accurately captures a record of work, rather than just any activity.

Q. Why not use a term like 'ticket'?

We conducted research with a diverse range of teams that had varying levels of technical knowledge. Although there were many common terms that teams used to describe their work, most were not broadly suitable. Based on the feedback we received, 'work item' was chosen as the most appropriate term for all teams.

Q: Can admins choose what term replaces 'issue'? Will this be a site or project-level setting?

No, admins will not have the option to decide what term replaces ‘issue.’ By default, ‘issue’ will be replaced with ‘work item’ for all Jira customers at the site level.

Q: Will this change be implemented in Jira Data Center as well?

As of now, there are no concrete plans to introduce this change to Jira Data Center in the near future.

Q: How can I see a preview of what this might look like in Jira?

You can use our Chrome extension and select 'work item' to preview Jira with the updated terminology. Please note that this extension performs a broad find-and-replace of terms and does not reflect the final implementation of work in Jira.

[David Pezet]

@Josh Sherwood Please review the comments from the previous announcement. There seems to be underwhelming support for the use of "work" or "work item." This should call into question the value of any previous research. If the term "issue" is being changed because it no longer accurately reflects how Jira is now being used, then it should be replaced with something even more inclusive of its current usage. Many use Jira "issues" to represent things that are not work, such as entities, objects, assets, clients, contacts, vendors, employees, etc. These items have lifecycles (i.e., statuses/workflows) that fit well within Jira's functionality, yet none of them are a type of work. I feel this change is simply replacing one problematic term with another and that it is being pushed forward despite valid, logical feedback.

[Dave Mathijs]

Please also introduce dozens of new icons to choose from for these work items, the current selection is way too limited.

[Stephen_Lugton]

@Dave Mathijs we replaced most of the standard icons with royalty free ones or ones we created ourselves as part of adding new ticket types:

[Jonathan Cyr]

"Jira will call the different items you track exactly what they are: work."

"Today, we’re excited to announce the introduction of work as the new collective term for all items tracked in Jira."

How can Atlassian not realise in their own phrasing that the obvious word here is "item", not "work"!

We used to say "Can you create an issue?". If you replace "issue" by "item" or "ticket" it still makes sense. But now it will be:
- Can you create work?
- Can you create a work type?
- Can you create a work item?

None of those sound good in English or convey an obvious meaning, especially not in the context of creating a suggestion or a user story for example. So many users mentioned to Atlassian in their previous post "Choose how you want to represent your work in Jira" that not everything is work, yet here we are.

I second what  @David Pezet said about calling into question the reasearch you have made on the subject.

[David Vins]

It's almost like they didn't read any of the reasoned feedback in their own community.

This sure will improve the myriad of use cases, such as where item "work" represents a physical asset, or a report, etc. JSM is going to be fun when every duplicative issues reported by customers are all considered work, too.

Meet the new boss, same as the old boss.

[Andrea Robbins]

It's ok - Jira users are going to continue calling them Jira tickets no matter what the official name is. 

The common thing I hear from development teams like in stand ups/projects is for management to tell them - don't forget to update your Jira tickets, so now it will sound weird - don't forget to update your Jira work items, don't forget to update your work, I just sent in a work item, or when will the work item ITS-1334 be done? It sounds so ODD.

I wish a whole new term would have been created - it would have helped Jira stand out instead of fit in with the other software competitors. 

[Rick Westbrock]

I always preferred to use the technically correct term so I would tell people to "Submit a Jira issue" and saying "Submit a Jira work" just sounds dumb.

Realistically almost everyone in my company has used the term card or ticket so this nomenclature won't really affect them. I guess the rest of us just need to embrace using a term that is not "technically correct" and ignore the fact that Atlassian is "solving" a "problem" that I don't think really exists with this change.

[Henri Seymour _Easy Agile_]

I understand that folks who agree with the change don't often comment on posts like this, but I might feel less apprehensive about this change if I could see any positive opinions for "item" / "work item" or stats on users preferring it. 

[Jonathan Cyr]

@Henri Seymour _Easy Agile_ Indeed. We did not get to see any stats or participate in any polls regarding any choices. Atlassian only wrote an article on Sept 24 asking us to choose between "work item" ot "task". No one in the comments really supported those. Although "Item" and "ticket" came up a lot as viable alternatives in the comments, they were never in the choices Atlassian forced us to pick from. Now, just 3 weeks later, Atlassian made a final decision. How ridiculous.

See: https://community.atlassian.com/t5/Jira-articles/Choose-how-you-want-to-represent-your-work-in-Jira/ba-p/2812617

[Rodolfo Romero - Adaptavist]

A want to add my voice to the comments from other people.

Please Atlassian, reconsider this decision. It is not aligned with the spirit of transparency and community that you are known for. The community has spoken and you are unilaterally deciding to ignore it and not being transparent as to how you collected the data to make this decision. It is clear that you did not collect it from the community.

Atlassian, if you're going to solve a "problem", then solve it right, or leave it alone and focus in many other things that have higher priority.

[Jonathan Cyr]

Granted, Atlassian was not exactly facing the following paradigm to begin with:

- If it ain't broke, don't fix it.

But they sure as hell jumped head first into this one:

- If it's not ideal, make sure to break it so it's worse than it was.

Next time, maybe consider asking admins for feedback. Especially those working for partners. They are exposed to multiple instances (DC and Cloud) in a variety of companies that have a variety of practices when it comes to issue types, request types, assets, reports, etc.

It is not relevant to ask specific users in HR or Legal about the term they prefer, when they do not have an overview of the entire instance and how it's managed and used.

[Don Erickson]

Please stand firm in having no concrete plans to implement this in Jira DC. 

[Josh Sherwood]

Hi all. Thanks for sharing your thoughts and feedback.

I understand there are some frustrations with the direction chosen, and I want to assure you that we've taken time to carefully consider customer feedback from various channels, including the discussion in the previous blog post, insights from our Chrome extension, and many conversations with customers.

While this update does not address all concerns, our primary goal has always been to improve the overall experience for all our users. This requires us to consider the broader use of Jira and its diverse user-base.

I know that many of you have been navigating 'issue' terminology for years. However, our research indicates that these challenges are more acutely felt by newer users and those outside of product or software teams. We reviewed many of the alternative terms mentioned above, but they were often found to be too technical or ambiguous.

We noticed that long-term users typically adopt their own language when talking about how they work in Jira, and we expect this will continue. Looking ahead, our vision is to align with this behavior by more effectively integrating the terms you use and minimizing the reliance on a single, 'catch-all' term.

While this won’t happen overnight, we hope this direction will eventually address some of the ongoing concerns that have been mentioned.

[Jonathan Cyr]

@Josh Sherwood You said: "This requires us to consider the broader use of Jira and its diverse user-base."

Your solution is not broad. It is too narrow! It already does NOT take into account all issue types that are NOT representing work. 

Why couldn't Atlassian just go with something actually broad, like "item" or "ticket"? Why mess things up by cramming the word "work" in there?

Baffling.

[David Pezet]

@Josh Sherwood (and @Arbaaz Gowher) I understand that "technical or ambiguous" terms may be intimidating for new users. However, the issue arises when they are no longer new. Once users gain experience and recognize Jira's potential, they also begin to notice the problems with the standard terminology. What is initially a small piece of the learning curve issue is know a persistent annoyance and only complicates educating the use cases for Jira.

This perpetuates the same problem. The fact "that long-term users typically adopt their own language" only exists because the narrow choice of terminology doesn't fit the real functionality. This will only continue if there continues to be a poorly chosen term.

Imagine a store only sells "Air Jordan" shoes so they develop their point-of-sale system to use 'Air Jordans' throughout. They grow into a corporation that sells franchises and one day realize they have the supply chain to sell other types of shoes. All of a sudden they have other types of Nikes, like 'Lunar Roams', being called a type of 'Air Jordan' in the systems (which is technically incorrect).

Many new franchisees aren't worried because they haven't started stocking other Nikes yet. Maybe staff may not notice or know any better, so they just brush it off. But the experienced franchisees tell corporate for years, "Hey, it's really silly that these things are called "Air Jordans" in the system. They should really just be called 'Nikes' because that's what they are, 'Nikes'."

Corporate finally gets up the gumption to get this straightened out since they realize it will help sell franchises. Since most of their stores sell Nikes, they start making the change. Meanwhile the stores that also sell Reebok, Adidas etc. say "Hey corporate, can we please just call them 'shoes'? That's what they are, 'shoes'. 'Nike' doesn't work for us, but 'Nikes' are also a type of 'shoe'."

Unfortunately since the train is already rolling, corporate replies "Sorry, maybe on the next go around. Good news though, its just the same problem you've already been dealing with." -- except really now the franchisees have to reeducate everyone that those 'Reeboks' are no longer called 'Air Jordans', they are called 'Nikes' (not to mention update all their own internal documentation as well). And all of this only for some of those 'Nike' stores to realize one day that they too can sell 'Reeboks', 'Adidas', etc... 

[Brent Lightsey]

I will input that I'm excited that Atlassian is moving away from the word `issue`. This has always carried a potentially negative connotation to me, as I first defined issue according to the PMI definition. It made me hesitant to ever use the word outside of our organization. I think this will be a difficult change but make Jira appeal to a broader audience, or just allow a more generic term. Now I can use the word `issue` in the project sense: a problem that must be solved or a question that must be answered.

[Oliver Michael]

How will this affect fields in JQL search? E.g. currently, I can search for `issueKey = X` - will this now be something like `workItemKey = X`? This affects many other fields related to issues / work items?

[Mike Marschall]

Just chiming in to leave a positive comment: I'm with @Brent Lightsey on this one, as not everything organized in a Jira project is necessarily an Issue. I see the benefit in using the broader term "work item" to fit everyone working with Jira and would suggest to read it as "an item that requires work to be done", or maybe even "an item in the context of (your) work", which is probably correct for 99% of users.

That said, I've yet to meet someone not talking about "tickets" with regard to Jira work items. I have a feeling that won't change because of this update (because it is, after all, only a textual change) and I can't really comprehend the passion with which some of the commenters here react to this update.

[Stefan Tichelaar]

Why change all "issue" definitions already available in the current Jira setup to work item? We have a deliberate distinction between Story, Task, CR (change Request) and Issue in place. If that changes over night to "work" then atlassian is deliberately braking our user instance??

Why not add "Work" as a select-able item and leave the very valid  "Issue" type alone?

I am always more for Extend than breaking interfaces...

Not saying adding "Work" as a term bad. I think it will help in understanding and adaptation in more production like environments that we also have in our company, for code development it makes not much sense to me though.

[Jens Schumacher - Released_so]

Why not use a term like 'ticket’?

Somehow the answer to that question completely avoided answering the question.

Ticket seems to be the most common term used that’s understood by technical and non-technical audiences. 

[Jens Schumacher - Released_so]

And as for data: A survey done on Linked in showed quite a different preference, with lots of folks in the comments preferring the term “ticket”.

And it wasn't even close. Out of 551 votes, Task received 198 votes. "Item" was an early favorite, but lost the lead after 100 votes.

Item: 17%
Work item: 19%
Tasks: 36%
Let me pick a name per project: 28%

[Denise Brown Horton]

If Atlassian is going to make a unilateral change to an important word or function, we ask that you provide paying clients the option to change the word, if needed, to fit within our own environment. Giving us the choice to use 'issue' or 'work' would be more beneficial than changing it to something that is unfamiliar to many people. The option to change the title of that category allows the paying customer to choose which works for them. Showing paying customers Atlassian is flexible, allows for a better environment of trust with the software. 

[Anibal Carracedo]

Hi team,

This has some impact on the API for getting the issues?