Issue workflow with many entry points

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?


2 answers

1 accepted

1 vote
Accepted answer

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?

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.

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.

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! :D

I think you've got two very strong points here - first that they haven't told you how they think they want to enter the data, and secondly that you can't really do it any other way in OnDemand.

If I were there, I'd be sitting with the QA team asking them why it's so hard to use two different issue types and why it doesn't work. Repeatedly. Because they won't be able to come up with a good answer!

Actually they did :p
They told me that it is not rare that they mark the defect as a "Code Defect" and it is actually a "Requirement Defect" or something like that. Creating different types of defects increases the overhead of changing its type (they would go through the "move" process in order to be able to change it).
I told them that this would probably happen on any approach we take because they would have to inform the system to which state the issue should be sent to.
We agreed that we would move on with the approach you suggested.

Thanks a lot for your help :)

That's not a good answer, that's them putting the wrong data in when they create it! :-) Punish them by making them use the difficult "move" process, then they'll be encouraged to do the job properly up front! (Yes, I am evil to users, sometimes it just feels so right... ;-) )

haha, I understand your feeling about the users, sometimes I feel the same :)
The problem is that it the error may not be on their side: our process is still maturing and it is not uncommon to create a "Code Bug" and found out that it is implemented as designed, so it would be a "Requirement Error".

0 votes
Joseph Pitt Community Champion Aug 03, 2014

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,299 views 12 19
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you