Reason for not changing assignee within project workflow?

I'm relatively new to JIRA administration and workflow config, though I've worked in software project and process workflow for a number of years. The previous admin at my company configured all workflows and trained users that the initial assignee should never be changed, regardless of the status of the ticket or current responsible party. Instead, custom user fields are set to indicate the code reviewer, QA and internal UAT users, who work the ticket once it hits the appropriate status. The user remains the original assignee (generally, the dev) throughout the entire workflow cycle. I've spent hours reading the documentation and watching online videos, but haven't found any good argument in favor of this practice. Is there something I'm missing that would firmly support the rule that the assignee should never change, even when the current workflow step is another individual's responsibility?

2 answers

1 accepted

1 vote
Accepted answer

No, you're not missing anything.   You've hit on the right idea, and, much as I usually avoid being so blunt, your previous admin was wrong.

The assignee field in JIRA is designed to be "the person who is currently dealing with this issue".  If they delegate parts of it out, fine, use sub-tasks or associated issues.  If it's a group of people, put a field on it for the group, but "Assignee" is always the answer to "who is dealing with this at the moment".  It should change during the lifecycle, unless it's the case of "I raised it and I'll do all of it".

For the other fields, actually, there's nothing wrong with them, and they can actually be really useful.  If you know who the code reviewer, QA and UAT users are going to be, by all means stick them on the issue and leave them.  They're useful for knowing who to assign to when your bit is done.  You can even put it in post functions.  For example "when developer finishes and moves issue from "in dev" to "needs testing", copy the QA user into the assignee field"

It's also not a bad thing to record "initial assignee".  Again, another field and a post-function to set it would save your users having to think about it, if you can't be bothered to glance at the history.  Or a scripted field to pull it from the history.

But, that core assumption that the assignee should not change is totally wrong.  Assignee = single person who is working on it now, and it will change as other users need to work on it.

Steven Behnke Community Champion Jan 06, 2017

Oh Nic, blunt is perfect. I run into so many people that think they know what they're talking about but in reality are just screwing it up due to a lack of understanding. You're a saint for participating so much here.

That would be based on what the previous Admin needed. Suppose they needed traceability back to the initial assignee (let's assume a developer). If they needed to generate some stats for each developer (lets say how many issues did they work on in a quarter?) then you might find it convenient to keep separate user fields for different responsible parties.  

Just one quick thought

Of course I would never say never...

Yes, but this information could be determined using JQL WAS operator (assignee WAS 'johnsmith'), correct? 

Yes, you could do that, but you would loose a lot of flexibility and might end up doing many queries for a simple analysis.

Nic's answer is what I would support, I was just trying to think of why the initial Admin might have done what they did.

I can't think of a good reason to work that way either.

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,663 views 18 21
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