I think there is room for improvement in the way workflows are implemented. I would like to be able to make the status (as in new, open, in progress, done) and their transitions independent for each workflow, so when I pick a workflow and customize it not to impact the other workflows and projects. For example we have one workflow and statuses for the incident handling and completely different for service requests and then another different for Change requests, etc. We should have a library of statuses and workflows, like templates, that we can pick from and assign to the project to start with. But from that point on, when we customize it, it should stay within the project and not influence other projects with the changes made.
Why I bring this topic here - both team managed and company managed projects can benefit from this. Team managed projects need independent workflow to suit their own pace and workflow. Company managed projects are in large variety and definitely can use more statuses and workflows without mixing with each other.
@Aleksandar Stamenov , can’t that be achieved using the Copy workflow? I get having a better library system. Today’s active and inactive presentation is poor if you have more than a few workflows. Having to scroll down to get to inactive and if you are cleaning up (deleting) unused inactive it takes you back to top, etc.
Following up on the question: Can I create my own templates - or rather, save an existing project with issue types, epics, and the pre-made issues themselves as a template?
hmmm... I'm not particularly impressed with the premise that changing the name of the two product designs is a meaningful distinction for managers or technical staff.
The classic vs novel is a widely-used dimension in marketing that supports conceptual recognition of the real-life fact that well-established or traditional tools and practices have an innate value due to wide understanding, acceptance, and existing support at the process and design level.
Alternately, tools and practices that possess currency provide the opportunity and the means to advance processes to accommodate business dynamism and freedom to innovate.
The Team vs Enterprise distinction is a dimension with a different focus and context dividing the roles and objectives of the business stakeholders from those of technology and skill stakeholders.
Neither of these knowledge-management dimensions differentiates Jira product features into clear and informative perspectives of the consequences of choosing to adopt one over the over.
The additional introduction of a 'template-based' selection product feature only re-confuses the unclear meanings of the "company-managed" vs "team-managed" terminology. Those terms have reverberating meanings and implications that will continue to introduce conceptual conflict into all marketing, design, and documentation verbiage that will more quickly than ever result in the scrapping of one or the other product definitions, or evisceration of one in favor of the other.
Historically, template-driven patterns result in stagnation due to practitioners who fully embrace their supposed rapid-design benefits or chaotic revisionists in the form of experimental implementers who advance the structure and integrability of the provider-designed templates until the templates are replaced by "template-design" tools introducing the need for a new skill-set of 'templaters'. This is the recursive path of Oracle, SalesForce, and low-code enthusiasts.
All of this is a new replication cycle of Atlassian's pattern of focusing on "grand scheme" competitive urges to 'lead the market' in every possible sub-market of IT Project Management.
The realistic mindset upgrade that will get them on target for delivering truly integrated feature-sets has to do with re-vamping the mechanisms of their platform that realize the abstract areas of issue- relationship-expressiveness, cross-discipline design process, and exposing business-operation visibility throughout the platform.
Currently, Atlassian's focus is exclusively limited to finding and grandilifying Product Managers who can imitate various knock-offs of single-purpose tooling advances that appear throughout the full range of digital business modeling.
This model is not sustainable and is actually anti-innovative and a fundamentally weakening dynamic of the product design, the process integrity, and the all-important conceptual plan that results in the accurate and truly useable, and verifiable product documentation.
Oddly, I'm going to come to Atlassian's defense about some of @Kimball Johnson's comments.
I think that the "Team-Managed" vs "Company-Managed" distinction is significantly valuable - at the marketing, manager, and technical staff levels. No short name representing a complex set of product features is ever going to provide a completely "clear and informative perspective" between the two.
But I believe this new distinction will help people when "choosing to adopt one over the over". Identifying the "project administration responsibility" really is a key differentiating factor between Classic and Next-gen projects.
While I have some empathy for some of the other points made, I think this naming change is an improvement. Not game-changing, but clarifying terminology and product intent is a Good Thing.
I love the new naming conventions for projects. It definitely makes a lot more sense and gives purpose to each of those project types.
EDIT: Also, thank you for recognizing that there is still a lot of value to 'classic' projects and that they have their place in the world just like 'next-gen' projects.
Follow up on the question about creating templates on Team-Managed projects and the response from @Bree Davies, how do you re-use an existing project configuration? I can't find any documentation.
@[deleted] When creating a new Classic project in Jira Cloud, it presents you with an option to "Share settings with an existing project". Using this causes the new project to share most of the Schemes and some (not all) of the other configuration associated with a project.
Some more info is here, under "Create a project that shares its configuration with another project".
I don't see anything similar for Next-gen (Team-managed) projects.
Hi All, @Bree Davies, can you advise if is/ will be possible to set default Access to Private for Team-Managed-Projects? We have had issues recently where users were creating new Next-Gen projects for their client engagements not realising that default access for these is Open (Public) and as a result other teams working on other projects have been able to (briefly) view details of these projects. As data security is critical for every business wouldn't the safe approach be to default new TMP projects to Private rather than Open? Searching for answers on this I found this issue has previously been raised here: Jira-Software-questions/How-to-set-by-default-Access-to-Private-for-a-next-gen-project but still not resolved it seems?
With the new changes will the statuses from Next Gen be removed from the dashboard search so that we can search just on the classic workflows? We find it hard to know which statuses to use with the next gen statuses in the mix.
Nice, but is there any chance of the highly-requested updates to the "Kanban" functionality that have been languishing in your backlog for 11 years ever being implemented? Thanks.
Thanks @Bree Davies, its good to see that this part of JIRA is moving well.
When can we expect team managed projects to be compatible with "Plan" so they also can be part of the full company roadmap with their initiatives and epics?
We have one team of 15 who are on "next-gen", the rest do "classic"
Will we be able to change the width of columns in the Next-Gen (Team Managed?) project boards? It appears they have a fixed width of 270px and that is ridiculously narrow, especially on a large monitor. I like the ability to quickly add items to these boards but the really narrow columns makes them annoying to use.
@Bree Davies My question is will ever be possible for the Team Managed project template to be customized at the account level or if it will always be controlled by you. It's time consuming to have to create the same issue types and status columns every single time we need a new project, and we would like to continue using Team Managed projects rather than switching to Company Managed because of the cleaner feel and simplicity. I would settle for an import option, but there is no ability to download a project that I can find, beyond exporting the entire DB, and I don't know what to do with that.
Thanks for the update and opportunity to provide feedback. I have today shared a view with your colleague Eoin on some mixing views about your launch and roadmap on Next-Gen projects and hope you don’t mind also bringing it to you.
On the positive side… I loved when Next-Gen was released! Your Why choose a Jira next-gen project? video on YouTube was key for us to decide to adopt Next-Gen last year – we now have hundreds of users. Our organization was new to Jira Software and it was fast to set-up, easy to configure and user friendly. Also, you stated in 2018 that “Next-gen will eventually satisfy all the needs that classic projects satisfy today, and more”.
On the other side… we now must migrate to Company-managed projects (former Classic) as your progress on Next-Gen roadmap did not move forward as much when it comes to our needs. Mainly because the inability to share custom fields across projects and the link to Jira Align apparently works much better with Classic.
I wonder if there are easy to use ways to migrate Team-managed to Company-managed projects?
I would also be interested to know if you hear from other organizations struggling with these issues (Team x Company managed) and how they are managing their internal rollouts?
Actually, there is one more long pending and high demand change is awaiting. We have not heard any plans from the Product team of JIRA.
I repeat the problem statement and the expectations as below.
Like me, there are thousands of "program managers" using the JIRA (cloud). The program manager is working on 3 or more projects Or multiple releases of the same project but work is happening in parallel.
We need to create the "filter queries (JQL)" for each of the projects (or releases). Example P1 Rel 5.1, P2 Rel 2.3, P3 Rel 6.4, etc. As of now the "JIRA" does not have any facility to put the "relevant queries under one folder". At present, I have more than 150 JQL (filters) and I need to search them or scroll multiple pages.
Can you provide the facility of "folders" for the JQL filters.
I am sure, that once you provide this "folders" facility - thousands of managers like me will appreciate that change.
140 comments