First off, let's definitely applaud that Atlassian after 20+ years is finally cleaning up vestigial leftovers from being just a bug tracker, I think this "work" is still better than "Issue" which can be synonymous with "problem" (which is clear from its origins that was the intent). And "Task" would not have been great since task is a common / default issue type and Epics are not tasks they're collections of tasks.
I think everyone also needs to acknowledge that Atlassian is a business and there is no business value to making this change at all, unless....
...unless they can use it as a marketing strategy, which if you read the new blog post: https://www.atlassian.com/blog/jira/work-your-way it is very clear that "Work" or "Work Item" is marketable for them following on the heels of merging Jira Work Management & Jira Software.
Also, Josh pretty much confirms it by saying they're trying to appeal to new users (marketing).
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 usersand 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.
Let's just be thankful for a small improvement and go on colloquially calling it whatever we want.
On that topic, no one suggesting letting this back end term be admin configurable could have possibly thought through the ramifications of what they are suggesting and the headache that would ensue from doing something like that both from a product development perspective for Atlassian and from an admin perspective.
Shoutouts & Kudos to:
Jonathan Cyr - who made a great point about using this in a sentence in English 👏
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oliver Michael I'm New Here November 20, 2024 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?
This. Exactly this. Am I going to need to update all of my filters and JQL queries embedded in Automation rules now?
Atlassian wastes time on changes no one asked for while ignoring their 20+ year backlog of valuable feature requests. Everyone is going to continue to call these tickets or tasks regardless of the issue type.
@Brock Jolet Considering how smooth the transition from "Epic" to "Parent" was, I doubt Atlassian's change plan was just shrugging their shoulders and telling everyone "good luck". Heck, users have been begging for this for years and the massive Change process required to overhaul such an integral component of the software was always one of the top reasons why it wasn't possible.
I have had such a hard time getting prospective teams/users to look past the word "issue" to use the tool - I suspect this will be much more popular than what is seen on this thread.
Having everything called issues is bad (and let's not forget that service desk has both issues and requests).
But calling it work??
So a user submitting a ticket asking a question is "a work"?
For those using a jira project for asset management (the old school way, not the overpriced jira permium asset management way), a computer item is now a computer work?
Better to leave it as "issues" until you come up with a proper alternative. And what kind of "research" is done and a solution decided and implemented in just 3 months?
Better to spend time fixing search, fixing UI inconsistencies all accross the place, fixing the messy vocabulary and management of users, agents, portal customers, etc... or the myriad of 20+ years feature or bug-fix requests in the backlog..
Maybe they used that "Atlassian Intelligence"...
Update January 2025: today I got an email letting me know about tickets with today's Due Date... Even this email is inconsistent. Email says "work items", email headline says "items", text says "work", and button says "work items"...
Also, how many years has it taken to have reminders based on Due Date..? and yet..
This notification does not tell me anything about which project they belong to, not even which site or tenant, nor the type of issue (sorry,work) or anything else.
My custom-made emails via Automation show the issuework item key, requestissue work type name, and the summary title of the work issueticket item, and their current status.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
1. I am assuming this is also going to move through the Chrome plugin for testing > Beta > Enabled on nominated sites > Interviews > GA? (similar to the new naviagtion) Is that right?
2. If so, is there an estimated rollout plan for this?
3. I would also like more clarity on what is replaced exactly on the interface of Jira, JSM, Confluence, Bitbucket, etc? Ie. screen shots or exact indications of everywhere the "find and replace" will occur. That would be really helpful, wouldn't it?
4. Lastly, referring to this
"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"
And on here https://www.atlassian.com/blog/jira/work-your-way - it seems that admins can have the flexibility to chose - so I suggest this becomes something configurable instead of it being changed for us. Thoughts?
Hi, I prefer the classic terminology, but my concern is that.. How this change will reflect on the result api call? example for the issuetype attribute? I hope it will not change in worktype. I have billion of scripts for customers or jira expression in validators... please give feedback about this topic
I like the term "work" because it is neutral and reflects the idea that something needs to be done.
However, I would like to know if the term will also be translated into other languages.
For example, in German, "issue" is translated in Jira as "Vorgang," which implies an active process (work in progress). In contrast, "work" would be translated as "Arbeit," which suggests something that needs to be done (work ahead).
Am I missing something here.... but if you are going to do an overhaul of something like this... why not make it configurable for the Admins in the first place??
When I design systems... the first thing I think about is Taxonomy - becuase it's REALLY important, and it's often overlooked in system design. But people are passionate about what they call things.
If I was overhauling this. I'd simply have two config items for "Issue", and plural "Issues", and convert all instances of the use of the term issue/issues into a read from configuration. e.g. Create issue, Change issue type, Issues.
Then release the config to admin who could set it to whatever they like, or leave it alone?
How is that improving the language/terminology in Jira? Already way too much overuse of the same terms for different things in Atlassian products, now want to make it worse?
If you must replace 'issue', why not a term like 'task'? 'Work' is too confusing.... "I worked on the work in the jira work management project in response to the the request work type in JSM, and submitted the work log to reflect it."
Oh, speaking of JSM... will this be across all project types? In Jira Service Management, it should be 'ticket' or 'request', not 'work'.
Will there be an option to refuse this change, like some of the changes like the "new" workflow editor? Or will provide the option to select what terminology to use with our organizations?
edit:
FAQ stated no option for Admins to change will be provided. That just reinforces that Atlassian will do what they want and will make up unsourced 'extensive research'. Also using the headline 'choose how you represent your work' as a misrepresentation of the planned reality.
In the Jira database structure and API, issues (or the coming new work) all have their own unique ids regardless if they are an 'issue' or whatever issue type or the issue key or project it is in. This means it is possible to have an overlay that is customizable, as proven by Atlassian in variety of functions and mechanics of Jira. Heck, you prove you can with the Chrome Extension! I know it is possible, to a point granted on cloud, with Scriptrunner Behaviours and custom plugins.
Likely will have more success selling this 'work' lingo change if you also provide flexibility for users and admins to implement our own terminology that fits best with our organizations.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Atlassian snatching defeat from the jaws of victory, yet again.
They're tickets. :eyeroll:
Jira tickets don't necessarily represent work: They can represent people, assets, etc. "Ticket" can be applied to any of these with no loss of clarity. "Work", not so much. Who says "Go open a work for that" ?
I do not agree with this change. I expect confusion. Users are already confused by just the two terms, ticket and issue, and I am not happy with the situation where three terms are added, including work.
Atlassian Team members are employees working across the company in a wide variety of roles.
January 22, 2025 edited
Hi everyone. I've updated the FAQ to address some of the questions regarding the impact on APIs and JQL, as well as provide more details about the rollout.
Next week, we'll post an update on our Atlassian Developer Community that will offer more detail. I'll share the link once it's available.
Q: How does this change affect Jira Cloud APIs?
There are no changes to existing APIs; they will continue to function as usual with the term 'issue.' New APIs will begin using the term 'work item.'
Q: What impact does this change have on JQL and existing filters?
JQL clauses and any existing filters/saved searches will continue to support the term 'issue' to maintain backward compatibility. We'll introduce a new alias for 'work' to support the terminology updates.
Q: When will this update be rolled out in Jira?
We're currently planning to roll out this change in March 2025. You can expect to see the updated terminology across your Jira Cloud and Atlassian products at this time.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I think it's safe to say that the community is quite perplexed about this initiative. The community has offered a lot of feedback on the issue, and it's not apparent that any of it has been heard. A company which includes statements like "Open company, no bullshit", and "Don’t #@!% the customer" in its corporate values is not living up to those corporate values if it doesn't listen to its customers any better than this, and only offers nonsensical explanations of its decisions instead. For the amount of money we collectively spend on Jira, it's not unreasonable to expect to be listened to when you invited us to the community, and you invited us to comment on your initiative.
There's a strong argument for making "ticket" the new name for a Jira issue:
Jira issues can represent other things besides work - they can represent people, or assets. "Ticket" is a well-understood way to describe a Jira record which represents a person or an asset. To describe a Jira record which represents a person or asset as "work" is awkward at best.
A "ticket" is a very well-understood way of referring to a Jira record - people say "Open a ticket" or "Create at ticket" all the time, and everyone understands exactly what that means. It applies equally well whether the ticket represents a bug, or a user story, or a feature, or epic, or person, or asset or something else. No one says "Open a work". Again, this is a remarkably awkward turn of phrase.
Can you explain why you would choose such a limited and awkward way to describe a Jira record, when better alternatives are clearly available? Can you explain why you would not choose an option like "ticket", which is broadly applicable, well understood, and clearly has a lot of support in the community?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Hey @Josh Sherwood, are you all also addressing "project" along this journey of change?
That has always been a weird term since a "project" would have an end (and most Jira projects never end). Atlas uses the term project and that is getting folded into Atlassian Home/Platform Experiences, so now there are two concepts of projects (with Atlas actually being the more accurate usage... but it is newer, so maybe that one will be re-termed?)
Feels like "space" could replace "project" since that is more accurate (it also aligns with Confluence)... or something similar to space could be appropriate... I can even see how "work" might fit better at that level instead of the issue level (although there is more than work in there and it still falls down in places such as "We should create a Jira work for that.".... "We should create a Jira space for that." :)
If you are breaking a bunch of things with renaming issue, you could tackle project at the same time (sorry for opening up a can of worms everyone)
Similar to others, I don't really think there is much of a problem with "issue" though. Maybe you can call them work for the plural version only? Then you can still tie into the marketing that you want and you don't actually need to change as much in the system?
Or just lean into type on its own in marketing, which still functions in JQL right now from even older times. That already fits into being branded as a "work type" and should allow for API calls and searches too (from that article: Just as today, you can still customize as many work types as you need...).
You could call the top level "work spaces" and these things that you are trying to rename as a group can be "work" but then an individual thing/item/issue is still an "issue" or a "type" and you can make sure it is focused to mean "topic of work" with that item. That still ties well into 'Work', your way (or keep the top level "work projects" and change even less... even though that term of projects seems less correct, it would be less work for everyone and the focus can be put on other things first).
Why "issue" is a fine term if you market around it a little differently:
It can be generic (like item and ticket and work and thing)
Topic is actually its first definition... an important topicorproblem for debate or discussion
Rather than thinking "concern" you can think of it as a topic or a periodical like a magazine... the new issue
It is a less bad term than bug and it doesn't need to be an ask or a request or a problem
It is a good noun and so you can "create an issue"
A positive issue in some cases and a negative issue in others
Even when it is an item of work that is with a business team, there is probably an "issue" that you are trying to complete because something needs to be changed and you have an issue with its current state or you just want to do creative things and want to issue them through a system
Hoping you consider our feedback for the final state of this change. Seems like making it configurable is a good idea while you are going through all of the changes on your side. Remember, new users don't know what they are doing at all and everything is going to be weird to them... so they turn to the community and we can help them (because we know this stuff really well).
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I see a lot of comments about Jira being used not for work, which is a good indicator of either not understanding the tool, or abusing it to do things it is not designed to do.
As a product company you should make decisions based on what the product actually is built for, not what people try to adjust it to be.
Jira is a task/work management tool where each work item is an instruction on something to be worked on.
It is not a database.
It is not a documentation tool.
It is not an e-commerce tool.
Every item you have in Jira is something that you should work on by following a process defined in a workflow that is then closed on completion and deleted in the cycles of your data retention plan.
If you use it in other ways, then you will just have to live with a term that does not fit what you are using the tool for. Just like the administrators of Jira have to live with trying to change Jira into something it is not built for. We have survived for decades and so will you.
---
For those who complain that you can no longer tell people to create a ticket or an issue... well, if you never used the correct term for what type of ticket or issue to create, then I see why you would struggle with this. 25 years ago I would have said that telling people to create an issue sounded stupid because you should define what kind of ticket or issue to make sense.
So instead of telling people to create an issue, tell them to create an Incident, a Change, a Service Request, a story, a task or whatever other work item they should create.
I can't imagine that is too difficult to do, and I am surprised people are not doing that already!
The only reason to use the generic wording is when you explain things in generic terms, for example for training purposes to explain how Jira work. You should never use generic terms when talking about how to do actually do something, as you do when instructing people what to do.
--
This change is helping us align the tools usage to make sure people are not confusing its purpose and try to (ab)use it for things it is not built for.
If you are struggling with using the word "work" as the generic description of what you do in Jira, then it is not Jira that is the issue I would say...
I, for one, give this two thumbs up, and I am hoping to see a change to the term Projects next since it is not accurate in the least, and it is adding a ton of confusion for people that don't understand the difference between an investment project for a CapEx budget and continuous development for a OpEx budget...
So instead of telling people to create an issue, tell them to create an Incident, a Change, a Service Request, a story, a task or whatever other work item they should create.
Now that we can create forms in Jira and not just Jira Service Management, I've created forms for all the types of work item that I want people to be able to create using user-friendly names. All the forms create whatever work item type I want, e.g. for the data governance team all the forms just create tasks.
Unfortunately we don't have portals available for Jira forms like we do for JSM forms, so I've created business area relevant Confluence pages as 'portals' with links to the forms.
One issue I have with using forms is that Jira forms only tell you that the form has been submitted and don't provide work item reference or further access via a portal, so I'm now tempted to just set up a JSM project to handle all the different forms via a proper portal and filter them to the relevant team boards
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Now that we can create forms in Jira and not just Jira Service Management, I've created forms for all the types of work item that I want people to be able to create using user-friendly names. All the forms create whatever work item type I want, e.g. for the data governance team all the forms just create tasks.
Unfortunately we don't have portals available for Jira forms like we do for JSM forms, so I've created business area relevant Confluence pages as 'portals' with links to the forms.
One issue I have with using forms is that Jira forms only tell you that the form has been submitted and don't provide work item reference or further access via a portal, so I'm now tempted to just set up a JSM project to handle all the different forms via a proper portal and filter them to the relevant team boards
I think you will find that a lot easier to work with, and it will have a lot more functionality to work with.
I see a lot of comments about Jira being used not for work, which is a good indicator of either not understanding the tool, or abusing it to do things it is not designed to do.
Or maybe yourself is misunderstanding Jira. First and foremost, Jira was originally built as a development and testing task management, a form of documentation of issues, tasks, and what was done, and a means of communication and coordination. The role has for sure expanded, as Jira could be used for more than just software development.
The term 'work' is an action, not a state or descriptor. We all use Jira for work because we work on the tasks and issues and tickets and items that the application helps to track and manage. It is not a 'work', we do not work on work.
The abuse is turning the application in something that opposes its origins and how it is being used by majority of organizations.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Or maybe yourself is misunderstanding Jira. First and foremost, Jira was originally built as a development and testing task management, a form of documentation of issues, tasks, and what was done, and a means of communication and coordination. The role has for sure expanded, as Jira could be used for more than just software development.
The term 'work' is an action, not a state or descriptor. We all use Jira for work because we work on the tasks and issues and tickets and items that the application helps to track and manage. It is not a 'work', we do not work on work.
The abuse is turning the application in something that opposes its origins and how it is being used by majority of organizations.
Like the article says JIra was originally built as a bug tracker, not a development tool. It has never been a testing tool, which is why if you want testing capabilities you need an app for that. Jira changed with Atlassian added Greenhopper: https://confluence.atlassian.com/display/GH061/GreenHopper+Documentation
Issues (work) are not for documentation at all as Jira is not a documentation tool. It is a tool for issue tracking and as such the tracking only makes sense util the issue has been completed.
Jira is a project management tool that helps you plan and track work across every team.'
Built for every team, Jira is how modern organizations take work from to-do to done.
These are the descriptions Atlassian has for Jira. You track progress of work from to-do to done.
Changing from a term that is only relevant to incidents and problems (issue) to what you actually do (work) and what the tool is designed for is in my opinion aligning Jira towards the tool it is today and not what it was 20 years ago.
If your organization is not using Jira for work, which is odd considering it is a work tool, designed for tracking work, then my question is what are you using it for?
50 comments