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

[Nic Brough -Adaptavist- · Accepted solution]

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?

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

[Nic Brough -Adaptavist-]

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!

[oscar albrecht]

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 :)

[Nic Brough -Adaptavist-]

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... ;-) )

[oscar albrecht]

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".

[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.