@Bree Davies Can TMP be restricted to using existing fields, statuses, etc.? It creates a huge mess when people create status and fields that are very similar to existing statuses and fields for example: In Progress and In Process or Business Justification and Business Reason. I find they mostly do this because they don't realize something is already out there.
As a part-time Jira admin, I am not excited about this change. When it was originally rolled out, we ended up with several "projects" that should have just been issues. At least one project that was created that should have been matching workflows, etc. for existing projects that we still haven't taken the time to clean up because "Jira admin" is not my actual job. I'm pretty sure this was intended to make less work for Jira admins, but so far, it's been nothing but a headache.
next improve, please (if it exists, at least be easier to find and parameterize)!!! When start a sub task, change the status of iten dad to IN PROGRESS (or another, it depend of your workflow)...
Okay, I can get onboard with this new naming scheme. I keep having to tell people here to NOT use next-gen projects because they're crap and they ignore me and get 4 months into the project before realizing they should have used a classic project as I suggested. Now, I am trying to figure out how to transfer a next-gen project into a classic project.
Could you come up with a method of converting a next-gen project to a classic project?
This is such a smart and seemingly simple change; I really think it goes a long way to future proofing the distinction... Thanks for all your hard work :-)
Really, Really need issue specific workflows enabled in the 'team managed' projects (like we can do in 'company managed',.. ) Have not seen that on the roadmap,.. any ETA?
I was confused because I thought "Next Generation" would be more flexible and have more features, not the reverse -- so I ended up needing to delete the project and move to a "Classic" project which felt like I was starting in deprecated land, haha (scary!).
With that, I'm really hoping we can change templates, turn on/off features, etc. -- so we no longer can get stuck in a project that can't do something that another could, and have to start over.
In that sense, it is still confusing that they're 2 project types. I hope instead, they're just 2 starting points of the same 1 project type. I hope that makes sense. :)
Carlos, exactly. The biggest damn problem is that you're stuck with that next-gen project and there's no method of evolving it to a classic projects with the entirety of the features.
Why didn't you guys rename "Next-Gen" projects to "Crappy Projects With Greatly Reduced Configuration"? Jeez, the months I'm sure it took you guys to come up with new names would have been better-spent improving the usability of Next-G^H^H^H^H^H^HTeam-Managed Projects.
LOL I just noticed that after making a comment, there's no 1-click way to get back to the article. Good to know that the same commitment to usability exists between your Atlassian Community site devs and your Jira devs. Loving the parity!!
It's just developer churn. Exactly the same reason they pushed out the awful Jira Cloud view that we were stuck with for years and then roll out a "brand new look" reverting back to classic Jira.
Hahaha thanks, Ethan. To your point, while I was trying to search my way back to the "renaming" article I noticed another article titled "Could Cloud Get Any Better?". Why yes, yes it could.
Not going to lie, this "renaming" honestly feel like Atlassian gave up on NG replacing Classic projects. I mean it was called "Next-Gen" for a reason, right?
While I do think the renaming will reduce confusion for users who are not aware of the distinction between the two project types, that's where the value ends for me. So a few value opportunities that would help us a lot:
1. A single reusable configurable template for Next-Gen/TMP would really go a long way for the less complex projects and standardize the way we do things across teams rather than the "from scratch" approach. Flexibility at the team level is nice in principle but in practice causes confusion, especially when rolling up reporting, and for people who work on multiple projects.
2. Ultimately, one project type that can start simple and offer opt-in-out of features to get to right set of features needed is the way to go and would eliminate the need to migrate from TMP to CMP.
IMO, the rest is just "bandaids on the boo-boo" and not "strategic" at all.
Next-gen gave the impression that it would supersede the Classic projects, which is why I chose it. I just thought the limited functionality was until feature-parity was reach with Classic. So this is a bit of a surprise.
Hi Bree, we need to do multi-project-management. We strongly depend on a good overview over all our projects alltogether. We would do this by using Portfolio - right? And if we want to use Portfolio we should abandon again all our next gen projects, right?
As a long time Jira user I have to admit I never found the energy to explore the New gen stuff. It just sounded buzz wordy and silly.. The new names makes it sooo much clearer what you're trying to achieve and I will definitely look into them. It makes so much more sense for teams to be able to have more control over their own processes rather than everything going through me.
@Bree Davies , makes a lot of sense. I'd love to have a chat to talk about key features which are missing currently. My worry is the naming brushes some of the current issues I face under the carpet.
So for a company with 1 development team delivering multiple products (but may scale out its teams, i.e. have 2, 3 or 4) what project type do you suggest is better? I notice slight differences in each such as labels being visible on the NextGen board but not the classic - small difference but useful to have them, so some feature make us want to go next-gen, but our company profile "seems" to fit classic....
Looking forward to the more mature and robust re-modeling of the TMPs wherein teams do not have to redo everything when something goes wrong and they need to switch.
140 comments