nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issue workflow with many entry points

oscar albrecht

In my company we make heavy use of boards to organize our work and we like the idea of having the issue transitioning through boards (issues that are done for the development will appear on the test board).

We would like to create a new step on this approach and we would like to have a design board (UX), in which the design issues would appear and they would be worked on, going to the dev board after that.

Our problem is that there are bugs that do not necessarily involve design, so they would have to show up directly in the development board. Others do involve design and have to show up initially in the UX board.

We are using Issues Statuses and workflows to make this transition, but now we are facing a problem that the workflow accepts only one starting status for the issue. Is there anyway I can circumvent that?

Thanks

Accepted answers

Nic Brough -Adaptavist-

There are a couple of approaches, but as you're using OnDemand, you only have access to one of them

Create two issue types, with two different workflows, one called something like "Bug - needs design" and the other just "bug"

The other options all require scripting or code, but like the one above, all of them also rely on some way for the user to tell Jira whether the bug needs design or not. Different issue types is a plain and simple way to do it, explicit for the user.

There are other minor tricks you can play with OnDemand that might be useful, but there's no point going into them until we know a little bit more about the beginning of your process - the two questions I'd ask are 1

How are you telling Jira the bug needs design work?
How are you planning/expecting to "triage" this and also check that the decision is corret?

All comments

Nic Brough -Adaptavist-

There are a couple of approaches, but as you're using OnDemand, you only have access to one of them

Create two issue types, with two different workflows, one called something like "Bug - needs design" and the other just "bug"

How are you telling Jira the bug needs design work?
How are you planning/expecting to "triage" this and also check that the decision is corret?

oscar albrecht

Hi Nic,

thanks for your help.
1- It is not defined, my initial idea was to set the Status directly on the bug creation (Waiting for Dev/Waiting for Design). I could also add tags and so on. Anything that can be done on the defect creation page would be great. The only thing that the team would not like to have is two different types of bug.

2-Ideally our QA team would open them and, if the issue is on the design, they would set them sa design defect. If it doesn't involve design, it is a development defect.

Nic Brough -Adaptavist-

The only way to set the status directly on creation is to use two different issue types.

You still need to define how you know what the difference is. Your second answer pretty much defines it anyway - why don't you just have "Development Defect" and "SA Design Defect" as issue types? Saves you having to indicate it with another field.

oscar albrecht

Yes, this is my opinion, but the QA team do not like this approach (I have no idea why ) I will mark this as answered and try to convince them, thanks!

Joe Pitt

I agree with Nic, it sounds like they want you to write code to make up for their wrong decisions or reluctance to do their job.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud