Atlassian just announced a new feature for Jira Cloud users: anyone can create a project, issue type or custom field. No need to engage the admin team! When I heard this at the Summit user conference, I cringed at the thought of cleaning up the new messes that end users will inevitably create. I’ve spent many years fixing poor decisions made by application admins and now end users, with even less knowledge and application management experience, are unleashed on the config? Yikes! A fellow conference attendee sitting near me exclaimed “but I just got our application cleaned up” and let out a large sigh. Atlassian also announced the 2,000 Cloud user limit is upped to 5,000 users. Now even more people can create a bigger mess!
A theme throughout the conference was “open.” It means being open in your communication, your intentions, open to new ideas, and more. I enjoyed that talk and I took it seriously. So, I’ve challenged myself to reject my original pessimism, embrace this change, and find the good in it. I spoke with a Jira Software representative at Summit but initially that didn’t ease my fears. It wasn’t until I tried out the new project creation feature that I calmed down, the fear subsided, and I saw the potential. I can appreciate Atlassian trying to simplify a complex process and free up time for busy application administrators. This also aligns with the concept of added workflow and screen editing abilities introduced in Jira Server versions 7.3 and 7.4. And yes, I was scared of those changes at first too. But guess what? The world did not explode and I didn’t have to fix too many botched workflows. 😉
Good to Know
These new project abilities are configurable. It’s a global permission, so you can decide which groups receive the power. You don’t have to use the default “Anyone” setting.
Projects created with this method are structured totally different from previously created projects. These projects are independent entities that don’t impact or share schemes with the other types of projects. I know what you’re thinking: sharing schemes is “the way” to easier maintenance! It will be interesting to learn how best to manage projects built in two very different ways.
Quick Tests
I created a project of this new type, created a new issue type, and a created a new custom field. Since these objects are decoupled from global settings, there’s nothing I’ll actually have to clean up later at the application level. For example, there’s no new entry on the Admin > Issues > Custom Fields page. I wonder how these objects are stored? Since this is Cloud, I can’t access the database to see.
The new issue type creation wizard prevents you from creating an issue type that already exists, which is great news. See screenshot. But, it can’t prevent other “human caused” problems, like dupes (think “Bug” vs. “Defect” in the same project), plurals, and misspellings.
As a test, I created a new issue type and called it “Epics” (with an “s”.) Now the test project has both “Epic” (which has the special association behavior you expect), and “Epics” which is simply a standard issue type. It’s not pretty but luckily this unfortunate action is constrained to the project where the issue type was created. All users will see both options in the JQL search however.
I also created a custom field with the new fields designer feature. I created a field called “Date” and selected the type as “Text” instead of “Date” like it should be. It’s a common mistake and end users are bound to make it. In the screenshot, you can see my lovely new field on the right and its purposefully ridiculous value. Again, since this unfortunate decision is constrained to the project, maybe it’s not too much of a problem. This team won’t be able to properly sort or query data in this field, but it’s not the end of the world.
One Observation
This leads me to my only real gripe. Atlassian also announced a project archival feature (yay!), but it’s only for the Data Center version of Jira. I think the Cloud version needs this feature now more than ever!
What happens when all your users create their own personal projects for every little item on their “to do” list? How does an application admin clean those up when they aren’t needed or when the creator leaves the company? What happens when you visit the “all projects” list and there are 500 more entries than there were yesterday? How does a user know which “Marketing” project to file their issue in, now that there are 5 to choose from? I’m not sure there’s a good way (yet?) to manage these scenarios. A bulk clean up tool is really needed.
Also, my Cloud instance is very small, yet very slow. I know performance is improving and is a priority. But I worry that adding all these extra elements (even the cool new stuff) could slow it down even more.
Being Open
After my very brief look into the new features, I’m willing to be open. Change is hard but I’m choosing to embrace it. New concepts and features certainly deserve a fair shot. It will be interesting to see what, if any, issues arise and how application admins can best address them.
What do you think? Are you open to this change? What are some pros, cons, scenarios, and considerations? Post your opinions in the comments field below.
Learn more about these features in this post or watch the Summit keynote starting at 1:02:50.
What I keep asking myself is how reporting will work across multiple projects once each project has been configured differently? Maybe most reports are really just for a single project, in which case no problem. But in a large organization, I think this may become a problem.
Excellent point, Matt. I remember the rep at the Jira Software booth, at Summit 2018, mentioned a future concept of templating the config for these new types of projects. So maybe there’s some multi-project reporting and standardization possibilities there?
I like the concept of allowing users to have some control over workflow and field administration. It would be nice if the users could build the project based on existing issue types and fields as well as adding their own. This way we could distribute some of the control while keeping key standardization. For example, we have a custom Risk issue type that we would like to have in all projects. From what I could see, the ‘behind the scenes’ is a separate structure, so one cannot add that “Risk” issue type to next-gen project. Same concept with Custom Fields – if it already exists, why not let the project lead re-use it. We can always exclude the project from filters, but if we choose to include it, we know the data is consistent (such as in a select list with organizational departments or business unit names). Looking forward to seeing where it goes.
Thanks for your thoughtful comment, Jenine. I think the reason you can’t share fields between the new “next-gen’ projects and the “classic” traditional projects is because they are not of the same type. The next-gen projects and assets are built with a totally different framework. In Atlassian’s “The new Jira begins now” webinar on Nov 7, 2018, they mentioned that all the new features they are working on (roadmaps, bulk updates, transition automation, etc.) will all apply to only the next-gen projects. It would be too hard to “write the code twice” so they could apply to both project types. They also mentioned that the “classic” project aren’t going away, and there will be no forced migration from “classic” to “next-gen.” We’ll see what the future brings!
Pingback: Summit Through the Years - Strategy for Jira®