Reimagining ‘work’ in Jira to better represent all teams

[Shane Kelly]

I am infuriated. I keep looking for something and can't find it until I realize, it has been renamed to "work ..." or "... work".

What the heck?! Why?!?

Just like Microsoft now. Renaming things. Next you will be removing awesome features like Google does, because "not many people use it ...".

Atlassian is a company as any other. Bait and switch is what this is called.

[Kelly Arrey]

@Shane Kelly Yup. Also, optimizing for people who haven't even bought the product in an effort to remove perceived barriers to entry, at the expense of incurring needless frustration and wasted time for literally millions of users who already pay for the product.

[__ Jimi Wikman]

@Shane Kelly @Kelly Arrey  Words matter and this change is just a small part of the rework of the Atlassian products towards a new Atlassian product line and a new focus.

Considering that pretty much all navigation is changing in the Atlassian platforms, the change of the word issue to work will not be the biggest issue, even if it does not help. This is a change and as with all changes it takes time to transition from the old to the new.

Atlassian is already removing unused features, and they have always done that. It sucks when you are one of those that actually use it, but that is part of being responsible with your resources to focus on what most people need and not what a few needs. If there is a hard core need for a small group, then there will be an app for it eventually and those that need it can choose to pay for it.

This is how businesses work.

@Kelly ArreyIt is not about removing perceived barriers, it is about using the wrong word for what we do in the product. It has always been an issue (see what I did there) and it has caused tons of discussions and confusions for no reason other than that Atlassian have chosen not to change the wording before now.

There is zero value in leaving Issue as the term for the work people do, but there is a value in naming it correctly as words matter.

Being frustrated over change in a SaaS platform that literally push out a dozen changes, or more, every week is pointless. As much as I get lost in the new navigation and the new wording, I know that this change is good in the long run.

Change is hard, but it is necessary.

Especially so we can get rid of words like Epic, Issues and Projects that confuse the crap out of people and cause problems in every organization I have seen.

So let's hope that we'll see Jira Projects be changed to Jira Workspaces next.

[Stephen_Lugton]

@__ Jimi Wikman with Epics, Issues etc. we already use custom issue types for some of our teams:

• One team is full of gamers, so for them we use Quests (for epics), Challenges (for stories) and Encounters (for bugs)
• With another team that has uses Deliverables instead of Epics

In general I create issue types depending on what we're doing so we also have things like Ad-Hoc Requests, Workshop (instead of Spike), Knowledge Transfer (also used for documentation).  Instead of asking someone to add a ticket / issue we ask them to raise an Ad-Hoc Request, put in a workshop, etc.

[__ Jimi Wikman]

@Stephen_LugtonThat is how most people do it, but you would still have the language of the Epics in all aspects of the platform, like the Epic panel for example and the level where the Quests, Challenges and Encounters exists in the hierarchy is still named Epic.

This is where the confusion comes in as a development team will have their Epics defined as features, a management or product team will use the Epic as more of a focus area and a strategic team will see them as initiatives, projects or even themes.

All are Epics, which is causing problems down the chain...

[Ronda]

My position is the same regarding the word (language) changes forth coming. It seems most software developers/engineers create things with other technical people in mind who this may make sense to versus considering those who need to communicate in daily operations with a non technical audience.

We in Service Management will still say to the customers - create a ticket for issues.  Create a "work" sounds ridiculous not to mention it is not proper use of the English language.

[__ Jimi Wikman]

@RondaI hear you, but I find "create a ticket" is equally silly because you will get the follow-up question "what kind of ticket" if you have more than one request type.

I always tell people to use the request type name instead when you tell people to create things, so it would be "create an incident", "create an access request" or "create a story" depending on what work item you want them to create.

Correct me if I am wrong, but besides a few standard Queues, is the word Ticket even in the Atlassian products?

[Ronda]

If I tell a customer to create a ticket, it makes perfect sense to the customer. When they enter the user portal they are presented the options for the "type" of issue or request they are seeking assistance with. The fact that you negate this shows me that you do not deal with users in ITSM. This is a very basic in standard for a Service Desk.

[__ Jimi Wikman]

@RondaDon't get me wrong, there is a whole discipline called ticket management, so I am well aware that that is what people refer to in ITSM and other support contexts. That does not mean it makes sense when you ask people to create a generic object instead of a specific one.

Just because everyone is doing it, does not make it right and generic answers tend to come with follow-up questions to get specifics.

Once you teach your users to refer to the request types instead, they will not revert.  At least not in my experience.

[Ronda]

Thank you for your input, but it's the end user I have in mind. They mostly don't understand our technical terms which make sense to you and I, however I know after 20 years in IT Operations dealing with customer facing issues, they will always use the common term "Ticket". We can agree, to disagree. 

Back to Creating a "work" to do my "work".. yeah. Done with this conversation as it will not change a thing.

[Shane Kelly]

Jira allows me to name Issues what I want. That is what makes it flexible. I can have "Documents" or "Employee" or "Bug" or, or, or ....

So in the end, it doesn't really matter what Jira calls Issues. What matters is that people working together have the same understanding of what is called what.

Therefore, having the menu named "your work" does kinda make sense, since this page show me what Documents to work on or what Employee needs onboarding etc.

Is this the essence of what Atlassian is trying to achieve?

It was never about "creating a work item" just as it was (maybe?) never about "create an issue".

you guys get my point?

[Carla Ann Rowland]

This is a dumb move. it causes a lot of confusion for the end user and a lot of extra work for Jira System Administrators. Way to go Atlassian just another thing we have to justify to our clients to stay with your products-- like we don't already have enough fighting off your competitors and keeping our clients tied into Atlassian Jira DC and Cloud. Just keep building those walls and don't fix errors in DC that have been broken for YEARS.

[Tim Fostik]

I am a huge fan of the product, but this seems to be a solution to a problem that didn't exist. There are hundreds of high-upvoted features that customers are actually clamoring for but instead the product team decides that what they really need to tackle is terminology that has been around since day one. There have probably been months of 'work' at Atlassian just to roll this out whereby they could have been focusing more on the nuts and bolts of making the actual experience of using the app better. That's the lost opportunity here. The change does nothing for useability. 

They could have tackled the weird behavior of being unable to remove a status from an active workflow (why?). They could have done something more with CSAT in JSM -- perhaps asking more than one question or automation-enablement for low scores. Maybe they work on making the customer portal better - allowing folks to edit non-critical fields after they've submitted a ticket or enabling transition screens. Maybe they dig into JQL conditions in workflows (strangely absent) in a system that largely relies on JQL everywhere else.. the list goes on.. and no doubt others have their own wish list.

Atlassian is entitled to build the app however they want, but having pseudo-feedback channels that they aren't utilizing is just disappointing. This thread feels like 90/10 opposed. I get that isn't scientific, but I bet it is representative of how folks feel about this change broadly.

Still love this company, and everyone gets off track occasionally. Let's hope they resume focus on making amazing products that enable teams. 

[Brock Jolet]

The changes have started rolling in and as predicted it is confusing our users... even admins.

We finally got people trained up and now every menu they learned is called something new or the top navigation is now an endless side panel of text and the thing that used to be called Issues is now All work.

Any day now Atlassian is going to change the smart values from {{issue.xxx}} to {{work.xxx}} and I'm going to have to update thousands of Automation rules that have been humming along for years.

Every year it costs more to keep the same features and the standard tier becomes less usable as the company locks everything behind premium.

Oh but did you know there's a new video platform? Don't care about it? Too bad, we'll keep showing banners to all of your users until someone accidentally clicks on it.

[Haddon Fisher]

But hey Brock Jolet if you upgrade to Enterprise, they'll stop letting your users sign up for new instances!

[Debbie Jolley]

and just to add to the layers of confusion, my sandbox still has 'issues' whereas my production version has 'work items'.

I genuinely don't understand how Atlassian are determining their roadmap - there are MANY things about the product that have needed improving for years, that admins are constantly battling against - yet someone thought it would be a great idea to change a term that whilst not perfect, works fine for the vast majority of users...everyone is familiar with it...and didn't need to be changed (but now needs to be explained to a lot of confused end users - and training materials/documentation is now out of date).

This smacks of the number of times devs tell me they can do a quick 1-line change in the code - with zero consideration of the knock on effect to QA; deployment; production; training materials; end users etc...

[Edie Hovermale]

Jira Team,

Not all 'items' are 'work'. Sometimes items are containers (epics), or things (Assets). Odd this was not thought through before making this change. We've got a bit of a mess here. As a Jira Admin I am finding it difficult to quickly find things in the 'Work Items' setting page due to the word 'Work' being everywhere. 

The word 'ticket' or just plain 'item' would be better. I am very disappointed.

[__ Jimi Wikman]

@Edie Hovermale That is an interesting distinction.

You do not consider the container to be of the type of work, even though it contains only work items? If the Epic is not something that should be worked on, which suggests it does not need a workflow as items can not transition without effort (which would be work), then are you using the Epic as a categorization?

What if you rename the Epic to Feature, would you still consider the container to be a category, or label, or does it become work if you do that?

As far as I know Assets have not seen any changes because those are not work items but data objects?

I am with you on the confusion to find things now, especially since the new UI is rolling out and there are so many UI changes happening every week, but it is just because it is new. We'll get a hang of it soon enough :)

[Edie Hovermale]

@__ Jimi Wikman
Tell me what 'work' you do through the Epic ticket itself? Epics are usually broken down into Tasks. An Epic serves as a Container of work, but usually not the work itself. The work is done through the Tasks. Perhaps you use it differently. No, these are not Features. And even if I added a feature, the ticket object itself is called a 'work item'. This new naming change to 'work item' was just not well thought out.

I realize you are a community champion, and as such you should read through all of the comments. This change is not well received. Perhaps you can help Atlassian with thinking through how these types of changes affect the community.