Jira Next Gen-Projects: From the User’s Point of View

I’ll admit that I didn’t expect to like next-gen projects, Atlassian’s answer to making Jira more simple, and creating self-contained projects that won’t impact the performance of your entire Jira instance. First off, I felt vaguely resentful of the timing – just as I’m finally figuring out the complexities of Jira, they come out with a “Dummies” version.  Second, I’m not a drag-and-drop type of person. I learn through language, by hearing and reading. I tend to find tools built for visual learners to be imprecise and a bit annoying. But I decided to put my reservations aside and create a next-gen project. Here’s what I found.

The Great Things About Jira Next-Gen Projects

Set up was fast and easy.  I had mapped out my project on paper so it was pretty quick to set up the issue types I wanted.  I added and ordered the fields I needed right there as I was creating the issue types, creating custom fields and adding choices to my dropdowns – all on one easy screen and with no schemes to worry about. 

I set up my screens at the same time that I created my first issues. Again, it was simple and intuitive. I simply clicked on Configure Fields on the Issue Create screen and now all of the fields I wanted are there.

These are two big advantages of next-gen projects. Set-up was simple and it’s really, really nice to know that I can create a project specific to my needs, without worrying that I’ll screw things up for everyone else.

And the Risks…

Time will tell if those two advantages also turn out to be the biggest disadvantages of next-gen projects.  While setting up the next-gen project was certainly easy, I wonder if the simplicity itself may cause users to miss out on something. When you wade through issue type schemes, field configuration schemes, etc. you are getting the benefit of learning from those who have gone before you. Seeing the fields that are used in other projects may trigger you to think about aspects of your project that had slipped your mind, aspects that may not be relevant to you, but are crucial to other users. I’m curious to see if, as my project evolves and I make needed adjustments, it will end up looking a lot like one of the default schemes.

While it’s nice to be able to create a project knowing that you won’t mess up what anyone else is doing, it also implies a higher level of responsibility. If this is my standalone project, with my issue types and my custom fields, then it’s my job to get them right and to clean up the mess when I get them wrong. It will also be my job to deal with maintenance – to keep the project clean, to make needed changes, to clean up the data when garbage gets entered. Simplified maintenance is one of the key advantages of shared schemes. It will be interesting to see, as use of next-gen projects grows, if maintenance becomes an issue. Atlassian has said that they will soon be providing the ability to extract next-gen project settings into their own template, and link two or more projects’ settings together. (However, they also say that if you want to share configurations, it’s best to go with a “classic” project.)

The other limitations of next-gen projects relate to them being new. Atlassian has published their roadmap, letting us know when features we’re used to using in traditional projects will become available for next-gen projects. App developers will also need time to catch up. For instance, ProForma – which allows you to create forms that embed in Jira issues – does not yet work for next-gen projects. I think I’ll create an issue for that.

Leave a Reply

Your email address will not be published. Required fields are marked *