Two different ticket types for one project

[Grégoire MANIEZ]

Hello there!

So I asked a question recently and it helped me a lot. Now I come with another question!

I would like to know if it is possible in JIRA Software to band two different ticket types for one single project?

For my own case, I seperate one project into two different kind of boards: one for development, one for QA. I managed to link some of the issues so they appear on one specific board as soon as they reach a certain state.

Now, the two boards should use different ticket types (development go for epic and stories, while QA goes for technical issue, graphical issue and so on).

And based on that, I want to have specific fields that show up based on the issue type (aka different board).

I tried many things but I'm stuck because I can assign only one ticket type scheme to one project, or in other words one project can have only one ticket type attached, which includes all my ticket types, and therefore I can't configure different ticket types and different field configuration.

So is what I want to achieve possible? I would assume yes, but I have no idea on "how". Or is there another way?

I could make it work for a custom fied I added, but the default fields are not in this category.

Can an JIRA master guide me? :>

[Nic Brough -Adaptavist-]

Ok, you've misunderstoor how issue type schemes work.  The statement " I can assign only one ticket type scheme to one project, or in other words one project can have only one ticket type attached, which includes all my ticket types, and therefore I can't configure different ticket types and different field configuration" is not right.

The issue type scheme tells the project what issue types it can use.  It does not have anything to do with the configuration of an issue.  You can put many types into a scheme, so your people can choose from many issue types. when creating their issues.

The configuration of an issue (the fields, workflow,screens to use, etc) is hung off the issue type - your people choose an issue type when creating an issue, and Jira looks at the associated schemes to work out what fields and transitions to offer to the users.

So, for your case, an example configuration would be:

• Issue type scheme has issue types of Bug and Feature
• Bugs have one set of fields, probably including "found in version", and Features have a similar set, but probably not the "found in version".
• The issue types may follow different workflows
• And so on.

 For your boards, I think you have another problem.  You say you want a development and a QA board, which is (not Agile, but) perfectly fine, but are these two teams working on completely separate things?  I mean you create an issue for developers to develop something, and another issue for testers to take a look at something to see if it works?

There's nothing wrong with that, but it's probably not what you want to do. 

Most would create an issue to get something done, and then have a workflow that takes the issue through the development and testing stages.  You don't create testing issues independently of the to-do item.

Is that what you're trying to do?

[Grégoire MANIEZ]

Hey, thank you for your time!

So our QA team doesn't have the same workflow as development.

For instance, a developer wants to create a ticket per feature (eventually epic, stories and tasks), while the QA will create a ticket per bug, there can be 5 tickets reported to one feature like there can be one hundred. In that case, components should work for classification.

That is why I don't think both teams can work one one single board. Especially since devs and QA also don't need the same fields. Both teams should ideally be on the same project though. Rightnow, I linked the states so when a developer moves a card to "To test", it appears on QA's backlog, and then QA can create his own tickets with a compoment to show it refers to that specific epic or user story.

Inb other words, different workflow, different ticket type, different different fields.

Right now, my boards are all set up and the only thing I'm missing to optimise everything is for instance, when in a QA board, not having epics and stories showing up (if they do, that's fine), but most importatly, after I select a ticket type, I want to show a selection of fields. Since the page refreshes after selecting a ticket type, in theory that should be doable.

Also I assigned different ticket types to different workflows (dev workflow and QA workflow) to one same workflow scheme including both but that doesn't seem to help in any way.

Maybe I'm just doing all wrong on JIRA (gotta admit it's not really user friendly on the configuration side of things :D), but this is the way we need to work.

[Grégoire MANIEZ]

I thought about what you said.

I think it might be doable to make everything work on one board only. Can you tell me if the logic is right?

So our board would have the classic lanes such as open > on progress > done (for devs)

, and then we add the classic QA workflow such as ready to fix > fixing > fixed > ready to test > deployed.

I assume a QA can choose to start reporting from the ready to fix column, using the "bug" category, and we forget about the bug category (or selecting bug as ticket type can open a sub-menu to choose?). If that is the case and if that makes configuration easier, I can definitely go for that solution.

I assume bug as a ticket type can still refers to any epic/user stories feature?

[Nic Brough -Adaptavist-]

Yes, there's quite a lot to talk about there, but I'll try to keep it short.

A couple of concepts to clarify first:

• Jira is an issue tracker, every item that needs attention is an issue.  But issues have different types - Epics, stories, tasks, tickets, bugs, features, tests, sub-tasks - all of these are issues, with different names.
• All the configuration (fields, workflows etc) is selected by project and issue type - a story and a test in the same project can work very differently, and differently again in another project.
• Boards are a view of a selection of issues, they are not a container for the issues (projects are the container).  Boards are built with the concept of board = team in mind (but there's no harm in creating non-team boards as a different view)

So, you should take a look at how you want to represent your issues.  Are they items for individual teams, or are they items that need to move between teams?  Or possibly both, that can work too because you can have different issue types work in different ways.

Imagine a simple story which has a lifecycle of To-do, in-development, in-test, in-delivery, done. 

Do you want to create a single issue that moves between teams according to where it is in its lifecycle?  Or do you create a development issue, a test issue, and a deployment issue for it?

If you're creating separate issues, then your board setup is simple - the developer board should select only development issues, and the QA board only selects test issues.

If you want a single issue to represent all the work to achieve it, then it's a bit more complex (Jira isn't designed for multiple teams to work on a single issue, it's aimed at multifunctional teams, where development, test and delivery would all be done by the same team)

Your board filters are simple - they just select all the issues.  But you configure the columns to represent the parts of the lifecycle each team needs to concentrate on.  The developers board would include all status, but all the ones that are after the developers finish would be mapped into the "done" column.  The tester's board would probably no map the pre-test status at all, the to-do column would start with issues that are in status "ready to test"

If you're taking both options - separate team issues and some that are cross-team, then you'll want to do the multiple board thing as described for the cross-team thing.