Two assignee fields

[Vanessa Becker]

Hi guys!

Can you have two assignee fields on a Jira Software ticket.

If not - what is the best way to deal with it if two people needs to look at the ticket at the same time?

I can add field for the Designer sign off but how do i assign to a tester and a designer?

[Lewis Cook]

Hi @Vanessa Becker ,

 You can't have multiple assignee's as far as I'm aware.

It sounds like you may be better off adding an additional Status in the workflow for the Designer sign-off (therefore allowing it to be assigned to them specifically). You could also setup automation or workflow transition actions to assign to a specific person OR person based on component - for example.

As you say an alternative would be to put a custom field of a user picker to illustrate who your tester should get sign off from as part of your process.

Thanks

Lewis

[Mathias Richter]

Hi @Vanessa Becker ,

For such cases, we typically recommend using sub-tasks. For the Task itself, you always need 1 single responsible user (the assignee). Otherwise, if 2 people are responsible, no one is responsible... 

You can create 2 sub-tasks as children of the ticket and assign a sub-task to each of the two users. 

Regards
Mathias

[Chris Tetzlaff]

Creating sub-tasks is the method we use to solve this. It's a clean process without any customization needed. 

[Frederik Vindum]

Having multiple responsible for a single issue does not give clear division of responsibilities. You can however, add a custom field to the issue screen which will let you enter one or more user names, hence achiving the desire to relate two or more users to an issue.

[Sergei Gridnevskii]

It depends on an issue. I can imagine a task like update 5000 records in DB that can be done by two DB admins in parallel. One can update 2000 and the other - 3000. Creator can be not aware who does what, he does not care, he wants the task done. Subtask is also not practical - after both do their part who should close original task?

[Nic Brough -Adaptavist-]

But which one is responsible for getting it done?  What stops either of them saying "I thought the other one was doing it".  You should never allow people to put themselves in a position where it's valid to say that.

[Sergei Gridnevskii]

When I have issues like that I give clear instructions in comments section. E.g. Joe please do your part and then assign the task to Sam. Sam do your part and close the issue. We have history in jira and whoever breaks the rule will be punished :)

[Nic Brough -Adaptavist-]

Thereby making the assignee field pointless, and responsibility really hard to track and identify.

Don't do that.

[Sergei Gridnevskii]

Yep you are right. For this particular situation of Vanessa I would create a special type of task, make two obligatory custom fields (Designer, QA), make workflow steps "In design", "In test" and make two rules that will assign the task to Designer field value when it is transitioned to "In design" and to QA when it is transitioned to "In tests". It will take me 15 minutes to finish and test it all.

[Johnny FromCanada]

From a Lean-Agile Team perspective (cross-functional, self-organizing), we want to avoid "hand-offs" from one person to the next, especially via tools.  However, the "Assignee" field in Jira has a long legacy of meaning pretty much that!

Consider a new custom field "Invitees" (multi-user), with description: "People to invite to peer-work on an issue".  Anyone who is peer-working on the issue is put into that field.  And even before that (say during Backlog Refinement), folks can add themselves to issues they would like to work on.  The person who eventually "pulls" the issue also invites the listed Invitees (who can still opt out).  We can also avoid a couple classic problems with a traditional mindset: "pushing" (assigning) issues to other people, or "reserving" an issue to work on later.

If you want to add other participant capacities, consider additional fields like "Consultees" (multi-user), with description: "People to consult on an issue".  They might be on the Team or even anyone else in your company.  Folks can add themselves to issues (say during Backlog Refinement) that they know something about, but do not necessarily need/want to work on directly.

Beyond that, IMO the value of additional user fields starts to diminish, and potentially starts heading back into silo/hand-off land.  At one org we have a "Testers" (multi-user) field, with description: "People to test the resolution of an issue".  A lot of the testers / validators happen to be outside the Dev team, and have bursty work of their own, making testing somewhat asynchronous and intermittent.  Not an ideal set-up, but something to work on going forward.  And the Testers field is tiding us over in the meantime.

The Assignee field is special in Jira.  We do not want to have it hanging around unattended, and possibly misused.  So, consider discussing with the Team to repurpose that field to mean something more general, like "Owner" or "Shepherd".  The Assignee's job can be to ensure the issue flows through the workflow all the way to Done-Done (per the Team's Definition of Done).  In RACI terminology, think of the Assignee as "Accountable" but not necessarily "Responsible" (although they are likely also that too) for the issue.

[Rilwan Ahmed]

@Vanessa Becker 

Create 2 different custom fields of type 'User Picker (single user)', name them as "Designer" and "Tester". Add them to screens. Don't forget to add them to notification schemes. 

You can also use User Picker (multiple users) custom field

[Andreas Springer _Actonic_]

Hi @Vanessa Becker

we answered this question in one of our articles a while ago. Feel free to check it out here: https://www.actonic.de/en/assign-jira-tasks-to-multiple-users/

We also have a beginners guide for Jira, if you are interested in that: https://www.actonic.de/en/introduction-to-task-management-with-jira/

Hope this helps. :)

Best,

Andreas

[Sergei Gridnevskii]

Cool, an instrument to make your product higher in google search results. The thing is that we need answers not links.

[Andreas Springer _Actonic_]

This is not about any product, it just didn't seem to make much sense to copy and paste our entire article here.

Sorry if it offended you, please just ignore.

[joe.robbins]

I looked at your post history @Andreas Springer _Actonic_  and this was the only link I saw.  I believe that you are not trying to build links on this platform but the conflict of interest apparent in your role and this post/your other posts takes away from what might actually be helpful info.  "Not about any product" rings hollow in that context.  

[Matt Doar]

I don’t think that the article linked to by Andreas was pushing a product. I’m not sure where Sergei got that idea from. And Joe’s comment doesn’t help because Andreas is clear about being an Atlassian partner.

Let's stick to the original question here, please

[agustin_alarcon]

You can have several fields where you can pick a user (or several users even)

Then you can name these fields however you like, but they will not be the "Assignee" field in Jira

[Anne Saunders]

This is how we manage QA Assignees - assigning an issue to our "Ready for QA" status or the custom field being filled in triggers a notice to the QA assignee's email and/or the QA team's slack channel. 

[Joseph Chung Yin]

@Vanessa Becker -

In Jira Software/JSM env, you cannot have multiple assignees assigned to the same issue.  I agreed with @Nic Brough -Adaptavist- I also disagreed with creating a custom field to host this concept.

I would recommend you to utilize the usage of Watchers/Requested Participants (out of the box) to handle this issue.  So the additional assignee can be alerted to the issues.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

[Chris Thomas]

I agree and think this is the correct answer.

[Sergei Gridnevskii]

I disagree and think this is not the correct answer.

As far as I understand Vanessa means that first designer works on issue and then QA checks his result and closes the issue. I conclude there should be a special workflow with steps made by designer and steps made by QA. For each of these steps we can assign appropriate person using Automation for Jira.

Your decision will make it hard to find what tasks should be done by Designer and QA respectively. They will need to check issues where they are watchers and look in comments. It takes much more time than just filtering by Assignee = myself and resolution is empty.

[Joseph Chung Yin]

@Sergei Gridnevskii -

My original input is simple without any additional customization required to address the ask using out of the box functionality.  You are right on one can customize the WF and switch the assignee at different transition steps.  You can also utilize Automation for Jira (assuming that user has the add-on in her env.

Best, Joseph

[Paul Cooper]

We use tasks or sub-tasks and assign these to individuals.

[Sergei Gridnevskii]

1. If you want to trick Atlassian create a group email for 2 or more employees and make 1 user in Jira. This works pretty well unless you don't care who personally works on the issue. E.g. you have a service and 3-4 guys that support it. Having one email for all is a good idea. And you pay much less for the license.

2. If you have a task that you think several people should work on, you may create a workflow that consists of steps to be done by one and other steps that should be done by the other. There can be an Automation rule that will assign second after transition to a specific state. This works well if you have a team that includes both developers and QA and you have states in tasks that should be done by devs and QA correspondingly.

3. (I prefer) decompose task to subtasks. Assign each subtask to a specific person. If you don't like subtasks - clone original task and set Blocked By link between two. Then assign each task to corresponding person.

I use all three approaches depending on project. 1 is good for services, 2 is for agile teams, 3 is good if you do not like complex workflows and prefer Open->In Progress->Done.

[daniel.szewczyk]

If you want to have two people to sign sth off you can look at adding an approval step to the workflow and require more than 1 person to approve it. Have a look at this article:

https://confluence.atlassian.com/servicemanagementserver/setting-up-approvals-939926369.html

Alternatively, as someone mentioned above split the task into sub-tasks if you need to track assignments as it's generally a bad practice to have one task assigned to multiple people (who is responsible in such case?).

[Sergei Gridnevskii]

> it's generally a bad practice to have one task assigned to multiple people

It is a good practice if team consists of several people with different roles. E.g. Product Manager creates a task and assigns to Team Leader, the latter decides who will do that and assigns to dev, dev finishes and assigns to qa, QA checks and assigns to dev-ops to put to prod.

But if they can work in parallel - then task should be decomposed, you are right here.

[Nic Brough -Adaptavist-]

No, it's really bad practice to have multiple assignees. 

It's fine to change assignees as responsibility over time can be different, but you should never never have more than one person as the assignee at a single time. 

And, yes, absolutely fine to decompose, or put "and other people may be involved" fields in, but the assignee must be a single person, the one who's responsible for making sure it gets done.

[Federico Scala]

Another option could be to create a sub-task to track for example the sign-off of the second person and assign it to him. It really depends on how your team works and how the workflow is built, which info should be tracked and which kind of tracking you need (dashboards? agile board?). Each option could ease one or the other.

[Adela Tataru]

If I am not mistaken you cannot have multiple assignee fields.

However you can create a custom field of type User and then eventually create an automation for the user to be notified when they are added to the issue.