You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I'm excluding Jira Service Management projects for this question.
So we currently have
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
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:
@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.
@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.
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".
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.
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.
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)
Recommended Learning For You
Level up your skills with Atlassian learning
Configure Jira Software, Jira Core, or Jira Service Management, including global settings, permissions, and schemes.
Managing Jira Projects Cloud
Learn to create and configure company-managed projects in Jira Software and partner effectively with Jira Admins.
Managing Permissions in Jira Cloud
Sharpen your skills at configuring and troubleshooting permissions in Jira Cloud with this free course.