nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is there a plan for resolving the disparate feature sets in different Jira project types?

Arnd Layer

I'm excluding Jira Service Management projects for this question.

So we currently have

company-managed vs. team-managed projects
software vs. business projects

This makes 4 different combinations.

each variant has their own feature set.

When team-managed projects were introduced, they were called next-gen, indicating a long term strategy to make this type the future.

At some time, some new features were introduced only to business projects.

So we have no option where all features are available. I think there needs to be a plan to make all features available in company-managed software projects - at least. It would be OK, if there would be a clear hierarchy where some types are subsets of other types.

With the current situation, I just tell my customers to mostly ignore the other features and always use company-managed software projects. All other options have too many caveats - especially it there is no option to migrate between project types.

However, there are some features not available in company-managed software projects that would be really nice.

It feels like

the experiment to replace classic projects with next-gen has failed or
the teams working on the different project types don't communicate.

Comments

Susanne Harelius

I am 100% with you on this. Such a mess. We are moving teams from a DC environment to Jira cloud and get so frustrated regarding this. We have 800+ teams to manage and we do not want to use the team managed since it has some drawbacks.

And with business projects, you cannot use parent links, so the cross-team plans become useless.

I could go on about this for "a while".

Matthias Gaiser _K15t_

@Arnd Layeras a marketplace partner who also has to deal with all these different project types and feature sets, I feel with you.

What I can say, that I'm part of a focus group working on a new workflow editor which is inspired by the team-managed workflow editor and aims to bring over the simplicity and usability of the team-managed projects over to the company-managed ones. This team has been highly responsive to questions and engaged in discussions. I have a good hope that these changes will be beneficial.

I'd love to see more of these initiatives to harmonize the projects again.

Amir Katz (Outseer)

For the subject - I agree. Let me choose the features that I need, I don't really care what it's called. Do I need Kanban? Do I need Scrum? etc.

For the underlying reason for this mess, I vote for reason 2 in @Arnd Layer's post.

You can see it all over Jira - either teams do not communicate, or there is no top-level manager who will make sure that they do talk.

To give a simple example - search.

There are 3 cases, rated from best to worst:

There is a search box and it's responsive - search is performed as soon you start typing in the box. Examples: custom fields, workflows.
There is a search box and it's not responsive - you have to hit ENTER or click on the search icon. Example: field configurations.
No search - you need to use the browser's CTRL-F to search the page. Example: workflow schemes.

Susanne Harelius

That sounds great!

Andy P_q7kohz

You can use Parent Link and they can be cross-project, with a Software project providing the Parent if you want, but you have to specifically enable the Parent Link field in your Business Proj to make it work.

Susanne Harelius

Ah, you can activate it? Our TAM said there was a change upcoming where it will be added.

Susanne Harelius

@Andy P where would that be?

Arnd Layer

@Matthias Gaiser _K15t_I hope that works out.

Sometimes though, I think it's these initiatives that create the outcome I've complained about ;-).

Arnd Layer

I'd even accept a good amount of inconsistencies as the price for innovation. But they need to be resolved over time.

Haddon Fisher

Being flexible enough to tackle almost any use-case was never going to result in a simple tool, but it does seem like they're leaning into confusion in a deliberate way in the past few years, particularly on Cloud.

Other people have pointed out how many of these choices seem to be self-inflicted, but I'd add in that not being able to convert between types is the artisanal Himalayan sea salt on the wound. Asking people to know what features they're going to need up-front is painful enough, but the "pleasure" of migrating when it proves to be the wrong one is deeeeeelightful.

Tere Pile

Agree w/this - as much as I like the Team projects for what they are - i.e. self management. They create a mess from admin level of consolidated reporting be it w/in the scope of Jira or when using 3rd parties.

It seems it would be easier to Allow admins to layer on some flexibility when needed (i.e. workflows) or fields. But ensure the company reporting/management can be maintained, i.e. if you want a new field that really doesn't exist, ask admin.

I think the above means the admin features needs some attention (schemes, screens, fields, etc) it can be overwhelming and because of this not open to all to avoid errors.

Haddon Fisher

Forgot to shamelessly plug JRACLOUD-78620

Anne Saunders

I have no idea of Atlassian's whys or wherefores on this, but it's maddening.

If we ever have to move to a more next-gen / team managed modality across all projects, our org will either get a different solution or finally break down and build our own. (We build custom / enterprise software)

Anne Saunders

@Amir Katz (Outseer) the search example you cite, where there's no consistent design and usage standard, is my pet software peeve. I can't be as efficient as I want to be when i'm constantly looking up or re-learning how to navigate edge case workflows and screens.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

project-type

strategy