Reason for not changing assignee within project workflow?

Alexandra Doyle January 5, 2017

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

2 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 5, 2017

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 F Behnke
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 6, 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.

0 votes
Deleted user January 5, 2017

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

Deleted user January 5, 2017

Of course I would never say never...

Alexandra Doyle January 5, 2017

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

Deleted user January 6, 2017

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 6, 2017

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

Suggest an answer

Log in or Sign up to answer