@Victor Burgos - sorry having a column on the board which is called CANCELLED does not help. Like "Done" this is a resolution status which MUST have tickets fall off the board immediately. They are not done, they will never be done. Having a new column on the board would leave titles with a status of "cancelled" but with a JIRA status for resolution of unresolved. (thus it would be a blue status in the workflow and not a gree done resolution status). Does this make sense?
Atlassian Team members are employees working across the company in a wide variety of roles.
June 26, 2019 edited
Hi @Rach - Next-gen boards can currently only have one column where tickets fall off the board (this is always the last column). This means that it isn't possible to have both a DONE and a CANCELLED column.
The good news is that this level of column and status management, where you can have multiple statuses on your boards that act as resolutions for your issues, is on our radar and we'll be adding it to next-gen projects in the future.
Hello.... Is it possible to set-up Program Increments (eg.: PI 1 thru 5) with each PI event containing several Sprints... with each Sprint having a 2 week duration? Thx.
Hey @Jason Wong - I am confused about Custom fields with Next-gen. If I already have several dozen custom fields in Jira, can I add one of those? If so, how?
If not, then I have to create a new Custom Field in the Next-gen project that has the same exact name as one I already have? So now there are duplicates because I couldn't use the already existing ones on Classic projects?
And if I need that same field on another Next-gen project, do I have to create it all over again (now a third one)? Or will it be available because I created it on another Next-gen project?
Great question. You are most likely familiar with the situation where Jira Classic projects are able to share custom fields via field configuration schemes. This works great for standardising, but has the drawback of the administrator perhaps being outside of the team which can increase the turnaround on adjusting project configuration.
The Next-gen projects are approaching this problem from the other end to enable teams to configure what's best for their project and so all of the project configuration in Next-gen is independent of other projects, and so you're right in seeing that no custom fields are shared. At some point in the future there may be a return to adding or merging in that capability to share configuration.
@Jason Wong - Any thoughts on the reason for standardization is so that organizations with 50 projects can have some type of uniformity when moving issues between projects? Generally speaking people who run individual projects may not have the experience to understand what is required to make a good flow. In complex organizations an issue can be reported in one project, moved to other projects, or cloned and moved to another project. What you are expecting is for individual project leaders (who frankly may know nothing about Jira) to have a consistent naming convention, status set up, and appropriate configurations for internal/external end-user use. I guarantee that is not going to happen. Instead of a learning curve for one person you have a learning curve for 50.
@Jason Wong - Thanks for clarifying. But how do you guide the user when they are using those fields in some type of automation? There will be MULTIPLE fields with the exact same name. How will they know which one to use?
Yes we've seen Classic projects stretched to both ends of the spectrum (central vs individual control);
Fully standardised control can result in teams asking for customisations, which puts pressure on opening up admin settings.
When admins opened up settings (by giving more people admin permissions), it then swings to the other end of the spectrum - where there are too many different admins making inconsistent changes (at times inadvertently conflicting with changes made by other admins). To add to your example (and @John Funk's on multiple custom fields), I've heard stories about the date field - inexperienced admins creating a (duplicate) date custom field as a text field, rather than date picker and so that leads to a lot of cleanup work. And so this then results in pulling things back to standardising.
To answer your question though, I think it comes down to admin style - do you let people learn by playing with the tool and making mistakes, or do you require admins to have some training/experience/learnt from your past implementations etc... before you let them become admins? I'd personally do a bit of both to help more admins skill up on Jira, but it really comes down to the specific implementation and setup for each organisation.
One observation I'd like to share is that, when you do go with too much standardisation, users who want to take things into their own control (but can't), will find other ways / tools that will then let them just do what they need to do right now. The data then starts getting recorded in say spreadsheets or physical wallboards, but this then leads to less visibility of the data and the same kind of data cleanup problem still exists, but now across multiple tools. There might even be the additional step of having to migrate that data back in to Jira. So while next-gen doesn't have a standardization aspect as yet, the complete independence of admin helps with onboarding more teams onto Jira where you can then see all the work in the one system and from there an ongoing engagement / negotiation on who standardised you'd like them to be with their project management data.
Organizations that use external tools linking Jira to a code base really kind of need the standardization for the tools to work. Each project is likely going to need some standardized fields/status. In next-gen they would need to be manually created in every project. Basically next-gen is almost a non-starter for companies with external tools already set up.
Have you ever tried to get 40 admins to do things the same way? It's like herding cats. You are correct that project admins are not going to have all the information necessary to not impact other projects. Many systems have multiple deploy pieces and they really need to follow the same process, so a release goes out correctly. We need to have the ability to create a global configuration that can't be changed by the local admin. Admins can set up rules in their own project to get what they need.
What about moving issues between projects that don’t have standards? Originators don’t always know where a ticket needs to be created. The engineering lead (after investigation) typically moves the ticket to the proper project. I haven’t tried with next-gen and incompatible fields but in classic that would definitely be a problem without standards.
Look at your own tickets. Prime example: How many upvotes are there for the issue on having a standard release version for all projects. I think it was 800-1000. That’s likely lots of different organizations. Another was sharing filters. Those are requests that have caused some of us pain for a long time. Initially next-gen didn’t have release versions which to me is crazy since it is a pretty critical value in many organizations. There are lots of problems discussed in the forums that next-gen doesn’t really seem to handle well. Honestly, I haven’t looked at next gen for a bit. No way I was going to it without the ability to migrate my classic projects without loss of data or some type of standardization that won’t break our current system.
You aren’t just training admins here. It’s all users. Having the ability to control the actions available in Jira prevents or at least makes it really difficult for inexperienced users to do the wrong thing. Big companies have people coming in and out. How are they going to know the process on each of these projects? Jira training is not always on the top of the list of training.
I don’t have issues with users and external tools. It would be up to them to put tickets back into the system if necessary. That isn’t a huge concern for me. I’m more concerned with the engineering process.
I'm sure I'd have more but even the new issue view is a non starter for me. Can't really go to that without lots of work either. The big fail for me is not having the ability to easily migrate my existing classic projects. How can Jira expect me to go to a new system that is going to add to my workload and not lose some of my existing data.
Atlassian Team members are employees working across the company in a wide variety of roles.
June 29, 2020 edited
@Mark Thompson I completely understand the use cases and examples you've given. I really like point 5 - that it's about training all users. Thank you for sharing those here. By linking this to the new thread, @ivan & @blim will be able to take a look and consider this for the future of next-gen projects. You've made some really good observations as to what you can't do with Classic projects that we would want to consider.
Could I get you to perhaps talk a bit more about why you need a way to migrate Classic to next-gen? Even things that may seam obvious - why starting anew may not work for you. Also what kinds of ways could we make the transition from Classic to next-gen a lot easier for admins and users?
Hi all, is there a way how to add new empty board in next-gen projects?
I would even like to create classic software project, however it would not let me for some reason to create anything now (always after creation shows project is not available ?!) so I can only edit my old next-gen project, but need 2 boards in there, any idea please?
@Veronika Mourková We've done this, with some caveats, but it's been a great improvement, without having to migrate the project to the classic version.
I believe the way we did it was to create a new board for a classic project, then changing the filter to only include the Next-Gen project.
Caveats: - Prioritizing by drag and drop doesn't work very well, specially when using Epics on the visualization
- Some features work strangely, and sometimes there's a workaround, sometimes not.
- Support is troublesome, since it's probably not an intended use
Hi there - looks like next-gen is no longer and is "team-managed" now? And yet choosing that reverts to company-managed and unable to find Features under Project Settings, as I need to enable all. Thank you! Amy
A Jira Administrator will need to grant you permission to create Team-managed projects if you do not have that already. That is done under Settings > System > Global Permissions
If you already have that, what do you mean by it "reverts" to Company-managed? Can you walk us through the steps you are taking?
144 comments