Project Keys

[Beth Pettit]

Can a single Jira project have numerous keys? 

I'd like to organize my Program, which is comprised of many lines of effort, using built in Initiative, Epic, Task hierarchy. Ideally, I would like to assign a different key to the issue type rather than the project to differentiate between work. (We are currently hard-coding change of naming convention on issue types, i.e. New Feature --> custom name 

We are managing customer facing requests in Jira Service Desk and we are standing-up a hierarchy to manage components of the program. I want to differentiate between these two without have numerous projects in Jira. How do I do this? 

[John Funk · Accepted solution]

Hi Beth - Welcome to the Atlassian Community!

No, each project can have only one project code, which is a part of the key (the key is made up of the project code and a sequential number). 

If you are using different Issue Types and different Components, you should be able to differentiate between the issues/work. 

[Clark Everson]

Though to aadd to John, if you change a project key in a project, then the old one can't be used because it can break links etc for tickets already created for it. Though, changing project keys for a project generally isn't recommended. Only Jira Admins can do it.

[Beth Pettit]

Thank you for the clarification. I ask because when I looked at an example of a project roadmap image , it appears as though there is a different key used for the Initiative, Epic, and Story. Do you have any insight you can provide? 

 

[John Funk]

That appears to be a marketing example so that people understand the different levels. 
Advanced Roadmaps almost by definition are a mixture of different projects in a single plan. You could certainly structure your plan like that using multiple projects, but I believe you are wanting to avoid that.

Bottom line is that you can’t create a plan like that with a single project.

[Dave]

You could certainly structure your plan like that using multiple projects, but I believe you are wanting to avoid that.

That's not 100% accurate @John Funk .... there are actually valid reasons why you'd want to associate different issues types at different hierarchy levels with different projects (although I agree that this would be more typical above Epic).

An example might be where you have a project containing Initiatives (or whatever level you create above Epic) and then have those as Initiatives the parent of Epics across multiple projects.

This allows you to create a project of Initiatives that overarch multiple projects. So it would almost be like a "Program Project" that just contains program level issues.

However, it's definitely not essential and you're absolutely right that you can't create a plan that looks like that using a single project as the issue source.

Also, I realise that the "you" in the sentence I have been quoted can be interpreted in multiple ways... either in general or specifically relating to @Beth Pettit's use case - my comment here relates to the general case.

Regards,

Dave

[John Funk]

Hey @Dave  - Thanks for the clarification. And granted having an Initiative in a different project is very valid. But the example in her screenshot above just isn't, in my opinion - having all of the stories in one project and all of the Epics in a totally different project and all of the Initiatives in a totally separate project would not be a very wise implementation - again, in my opinion. 

My focus was on the fact that Beth didn't want multiple projects and wanted to have multiple project codes in the same project. 

[Beth Pettit]

@John Funk @Dave  Thanks for the feedback. This leads me to another question. I am managing a Program comprised of about 6 major lines of effort plus tracking customer requests in service desk. I was planning on using the Initiatives feature to distinguish between these projects. Is this a good direction to head or would you recommend we maintain individual projects in Jira to track these? What are the pros and cons for this approach?  Thanks in advance for your help.  

I planned on decomposing the work as follows: Initiatives for the Lines of Effort/Projects, Epics as the summary tasks, tasks and sub-tasks to further decompose the work. 

Thanks again for helping this newbie learn Jira :) 

[John Funk]

Hey Beth - being new to Jira, I would say start small and expand from there. Jira can be a little overwhelming at the beginning, but is certainly very powerful to accomplish a lot of things. 

We tend to organize projects in Jira by teams of people. For JSM stuff, a lot of people create separate JSM projects by customer. I think both of those are good approaches. 

To be honest, I don't think it really matters which project the Initiatives are created in. I tend to use the largest project to create the major items in so they are a little more streamlined in a single project. Then add others around that. 

Your key for the plans is going to be based on the boards it uses. So I would start small, and add things as you go along to see the effects. Then you can pivot in another direction if it is not working well.