Customise an issue types schemes and Projects

[Shani Mamka]

Hey everyone,

I have 2 projects: software development and marketing.

1. I set the development project to Scrum project, what should be the project type for marketing?

2. What is the best practice issue type for Scrum project? User Stories and sub-tasks? or it's better to specify more issue types as needed (but then we lose this agile structure)?

3. What is the best practice to link an issue type from one project to another? I know that I can use the relate field to do so, but then I lose the user store sub-task structure again.

Thank you,

Shani

[Dave Theodore [Coyote Creek Consulting]]

1. I set the development project to Scrum project, what should be the project type for marketing?

I would probably use the "Business -> Project Management" or the "Business -> Task Management" Blueprint.  This should get you close and then you can adjust the Scheme settings to tune things for your exact needs.

2. What is the best practice issue type for Scrum project? User Stories and sub-tasks? or it's better to specify more issue types as needed (but then we lose this agile structure)?

Textbook Agile states that a User Story should be the most decomposed piece of work. Given that, you should not have a Sub-Task for User Stories.  In the real world, however, we see this frequently.  I suggest thinking through a methodology that works for you, but keep the Sub-Tasks to things that are related to the User Story rather than further decomposition of the Story.   For example, maybe you have technical documentation that is required as part of the Story, etc and make a "Documentation" Sub-Task issue type.

3. What is the best practice to link an issue type from one project to another? I know that I can use the relate field to do so, but then I lose the user store sub-task structure again.

There is a feature called Issue Links in JIRA. This allows you to create relationships between issues that are in different Projects.  Sub-Tasks, on the other hand, must reside in the same Project as the associated parent issue.  Issue Links allow you to interact with other teams and set up dependencies, relationships, etc and allow each team to use their own workflow, fields, etc. We see most teams use both features and they use the Sub-Task to indicate relationships within the team and Issue Links to indicate relationships with other teams.

[Nic Brough -Adaptavist-]

The project type is not a strong indicator of what the project is for, it's most important when creating a project, as it sets up stuff dependent on type, but after you've created it, you can make changes to the project that make it look a lot more like another type of project (and even change the type later)

So, question 1:

Development projects using Scrum is fine.  Marketing is a lot more fuzzy, so I would look at how they intend to work. 

You might want a basic "task management" type process, in which case one of the "business" type projects is probably best. 

If they want to be a bit more Agile, and have a flow of things coming in and going out represented on a board, then I might push them towards Kanban (although if you're on JIRA Cloud, you have boards in business projects which may be enough). 

Scrum is probably overkill, marketeers don't tend to work through a fixed list of items in a fixed time, there's too many dependencies on, well, customers!

Service desk might be an option if your clients come directly to your sales people.

Question 2:
Whatever works for you.  I'd start with the defaults JIRA gives you and build on that as you find you need it (The defaults do Epics, Stories and sub-tasks, and there's no harm in adding more types of sub-task if you need them, or things alongside stories either)

Question 3:
You don't.  An issue type is an artifact that helps you configure what is in a project.  Project A contains issue types 1, 2 and 3, project B has 2, 3, and 4, Project C has 5 and 6.  All separate, even though the issue types are shared.  The projects contain the issues, of type X