How to assign a issues to two assignee?

[Yoon Choi]

I want to assign two people for one issue.

[Paul Greig · Accepted solution]

Hi Yoon,

There are a few solutions for allowing multiple assignees to issues.

1. Create a Queue - Set default assignee as 'Unassigned' and create a dashboard with a filter on all 'unassigned' issues. Users can then select issues from the queue
2. Using Sub-Tasks - From the initial issue you can create sub-tasks and have these assigned to each user
3. General User Account - Create a new user account, let's say 'team a', to represent the team you would like to work on issues together. Once created you could assign the account, 'team a', to the issue.

There is also a great article available here on a similar topic with some additional examples:

https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users

Cheers,

Paul

[push]

Personally, I find it ridiculous that multi users cannot be supported. It's just another table and foreign key reference. 

Why some people are finding that hard to comprehend at Atlassian surprises me. However, if I'm incorrect I'll gladly accept the explanation

[Uma]

Trello has the feature and I am not sure why a simple requirement such as mutliuser assignment is still not available. Shocks me!

[karim harvey]

For the things that are supposed to be simple, it takes too long to configure and functions are too nested. This should be a standard feature in Jira that sticks out, the fact that I actually have to Google search this is a shame.

[Shaikhah Maasher]

I found that many features not supported in Jira board compared to Trello, this is really frustrating sometimes as I took a lot of time to manage finding temporary solution for a simple feature like this one. 

[Kael Hankins]

@karim harvey as much as get annoyed when Atlassian tries to decide what is best for my business processes, I give them a pass on the complexity front. Jira is incredibly adaptable and that leads to some truly arcane constructs and non-intuitive UI design.

[Manish Chacko]

@Kael Hankins  After searching for a long time, I've realized that the only way to solve this is to switch from Atlassian to ClickUp-check out their feature!!!!

 "Multiple Assignees – Collaborate together on a single task"

Ironically, Trello (owned by Atlassian) supports this feature!!

[Silviu Marian]

Wow Jira is so complicated! It has so little to do with Scrum! :((( Why don't you guys add features to the greenhopper plugin like multiple users on one task?

[Dan Driscoll]

We understand that Atlassian has provided a bunch of "workarounds" for this missing ability.  And that's just what they are, "workarounds" until multiple assignees are supported.  Unless some other tool has a patent on the concept that prevents Atlassian from implementing it. 

Also, there's a difference between responsibility and accountability.  I'd argue that RACI clarifies this and puts forth that Accountability is singular, while Responsibility can be held plurally.  And especially in our Agile worlds of collaboration and pairing or swarming. 

Must we really continue to have to leverage those "workarounds" or clone sub-tasks to map to multiple team members?    Is this one a feature list to vote up somewhere?  Or just constantly closed for comments (not this one yet...)?

[Kael Hankins]

This drives me crazy with Jira. For something that is so flexible in most cases I keep running up against these hard limits that people have been using hacks to deal with for two, four, six YEARS.

[Nic Brough -Adaptavist-]

It's really bad thing to do, that's why Jira does not have multiple assignees.

I've been engaged more than once to clean up the mess made by doing it, in a couple of cases, by the very people who were arguing for it here in community.

[Kael Hankins]

Why is it a bad thing to do? People can make a mess of anything.  

[Nic Brough -Adaptavist-]

Everywhere I've been that allows multiple assignees develops significant problems with "I thought someone else was doing it" (and often two people working on the same thing without co-operating).  It's a terrible thing to do and it always always fails.

By all means, name other people as involved or interested, using group pickers, user pickers or select lists, but you should never have more than one assignee.

[vpossoz]

I disagree with you, and for one single reason... "Individuals and interactions over processes and tools".
If a team wants multiple assignees and the risk is a messy project, so be it...  
What Jira is doing is just forcing people to use a tool the way they envisage it without any opportunity to accommodate for specific situations.
It is quite common nowadays to do pair programming, it would be outstanding to be able to capture that in Jira natively rather than having to create 2 sub-tasks assigned to 2 different team members or any other workaround that partly satisfies the goal. 
Scrum is about empirically tweaking and improving the process, Jira is everything but that. :(

[Chris P]

If the users are mistaking who is supposed to do the work that's on them and their organization. I get it's your opinion (and hard coded by Jira) that two people should never be assigned but that's how my organization functions and we find it ridiculous that yet again we have to hack our way through some Jira problem. It's tiresome.

Someone's ivory tower opinion on how our organization functions shouldn't dictate what I'm allowed to do in Jira - leave that to the people that pay for the product.

[Nic Brough -Adaptavist-]

The "ivory tower" is thinking that multiple assignees works.  Outside the Ivory tower, in the real world, it does not.

[Nathan Burns]

That's an absurd thing to say. If you think there's only one way to do things, why can we configure anything in JIRA at all?

Our team often pairs on stories. Github allows co-authors on commits for this very reason. I currently assigned a task to myself but right now the team has no idea what my pairing partner is working on. That's a problem. If it's not your problem, perhaps don't respond.

[Nic Brough -Adaptavist-]

I think you might have missed some of the context that has gone before.

My feeling is that is absurd to assume that when you have several people responsible for something, you can always go to the one that is responsible.  This sort of works in a quantum world (which we probably do live in), but that responsibility identification still requires an observation that collapses the wave function and hence lands on a single assignee.

There are loads of ways of working and doing things.  It's not absurd to require a single point of contact for something that needs doing.

Coding (in the sense of uploading to Github) can easily be co-operative, and pair-programming is let down by "single assignee".  But neither of those really matter when it comes to "assignee". 

As I've said many times in this thread, pair programming is the one time two-assingees works fine.  And also falls into "it doesn't matter, as long as one of the pair is assigned".

I'll fall back on the question no-one has yet answered.  Can you give me a case where you have two assignees on an issue where neither of them can legitimately say "I thought the other one was responsible for this"?

[push]

It does seem like a simple feature request, that could be optional for those people that need it and those that don't. If we need to justify why a simple feature doesn't exist using a wave collapse function and quantum physics concepts like entanglement and schrodingers uncertainty paradox, maybe that is indicative of the problem itself. 

It's a simple request, that could be implemented in a simple way.  At least to those of us that are software engineers.

If it's a engineering decision fine, but lets be honest about it, as afterall, it's a fairly honest request that clearly some users do have a need for, and whether this is good practice or not, it's clearly something supported by other platforms.

So maybe Atlassian should have a big long think about that before the wave function collapses on them and the probability becomes certain, although as an engineer, I feel like this wave function we're talking about, collapsed long ago,

Best,
Adam

[Nic Brough -Adaptavist-]

I think you're missing the point that there is no one that needs it.

[Gerard Dalmau]

I've been reading a bunch of comments and I've only seen people asking for this feature.

Whether you like it or not, it's a feature asked since 2003 that we are missing in JIRA, which happens to be a paid product, and is already used and working on other popular project management tools for free. I don't think the way the users use such a basic feature should be JIRA's concern.

If you want users to follow your road, just allow one user to be assigned by default, but you can be flexible and let an option in the project settings that allows multiple assignees on an issue.

[Nic Brough -Adaptavist-]

I think you have not read any of the explanations of why this is not in Jira and why it never will be.

[vpossoz]

Nic,
Stop been patronising and obnoxious.
As much as you don't care about what we want, we don't care about your lectures.
Just give us what we ask for and pay for.
Regards, and goodbye.

[Nic Brough -Adaptavist-]

I am sorry that you feel I am being patronising.  I do not mean to.  But it is hard not to come across that way when someone is not listening or understanding what is being said.

I can't give you what you ask for, I have no say in how Jira is built.  I can say that I wouldn't do it, the same way I wouldn't give a loaded gun to someone who has asked what shooting themselves in the foot is like.

[Marek Mandau]

Assignee could be split into 2 fields as a core Jira feature:  Lead assignee and current assignee.  That way the person responsible is always Lead assignee but the current assignee could be e.g. 5 people at different stages of the ticket.  

To make this more than just a custom field, each of the 2 fields should have Jira native support in reporting and backlog summaries so that workload can also be balanced.  

Any reasons this is not a good suggestion?  

[Marek Mandau]

If there's a better way to indicate Lead assignee for a ticket, a related button could send the ticket back to the lead assignee without having to look up and deduce that from the history, ask around who it was, or send back to the wrong person by mistake. 

[Marek Mandau]

Actually, the "User Picker (single user)" custom field is perfect for indicating a Lead developer. 

(You could technically also use a "User Picker (multiple users)" custom field for tracking multiple contributors to a ticket, but caution is advised.)

[Navneet Nair]

This was an issue raised on 2013. If Atlassian does not want to solve this, they are either deaf or just do not understand how work happens in the real world... Sorry guys but as much I would like to like you guys, Jira is terrible to work with...

[Nic Brough -Adaptavist-]

There is nothing to "solve" - assignee is a single person by design, for the reasons discussed above.  If you need to include other users, use custom fields to do it (also discussed above)

[Mehdi Bellatig]

so obnoxious in your answers Nic .. No, wether you like it or not, there are use cases where we need multiple assignees on a task (case in point, so many people are asking for it), not everyone is a developer, we use it for marketing with checklists and multiple people need to be able to see it on their board.

[Nic Brough -Adaptavist-]

I get grumpy when people ignore what has gone before.  Your statement is, as shown above, wrong.  Please don't be rude to people who are trying to show you where you are wrong.

[Luis Garnica]

So never mind the expression The customer is always right? 
Fine, let's ditch Jira, so many options out there, it's actually your loss. Not mine. Not ours.

[Kael Hankins]

@Luis Garnica Yeah, it's a shame but I'm not at ditching Jira levels yet. So far I've only been told I'm doing it wrong a couple of times. It's not like this has to be a recommended feature of anything. Hell it could be hidden away under an advanced section or labs or do-this-at-your-own-risk header. 

[Nic Brough -Adaptavist-]

"The customer is always right" is often quoted and even more often misunderstood.

It actually means that a service provider should lie, telling the customer that they're right, and then provide the service that the customer needs, not what they thing they want.

I prefer brutal honesty myself - you don't allow multiple assignees because, no matter what you think you want, it does not work in real life.  As I've said before, I've spent so much time sorting out the mess made by multiple assignees, I cannot tell you enough how bad an idea it is.

[Luis Garnica]

Great Jira feature! now it can also decide the best work model for my company!

Sarcasm apart, IMHO that is a problem of the company, not the tool. The tool should be flexible.

I my current company colleagues in the same team can work in the same issue. I can be working in an issue with high priority but then a new issue with highest priority enters the kanban which requires my expertise to solve it. The issue I was working on can be picked up by another college so I can work in the one with more prioroty. Since we are watchers we know what's going on. 

The problem is that we're constantly changing the assignee and we can't at the end have metrics of how many task solved each colleague or how much time they spent doing their part.

Another case of use: a tasks which requires more than one worker because multiple reasons:

- planing, just planning like "you handle the X part since is your expertise and you the Y part since it's legacy and you have better knowledge..."
- multiple time zones (ergo more than one person working on an issue)
- a needed intervention from a collage in a different team like "hey <member from data analytics team> please proceed to benchmark that ML model we (sre team) just deployed in our new instances with different GPUs" and comment the findings.

My current company is a high growth startup and we have "multiple assignees" in so many tasks. This has never been an issue, even more, is part of our culture, we have a blameless environment and we're all involved towards the same goal"

I've worked in the past in consultancy/enterprise (much less flexible than a startup) using ServiceNow and we had NO issues with multiple assignees in tasks (which ServiceNow handles quite easily)

I trust you have encountered many cases where multiple assignees have been a bad idea. But that's a problem "they" had. Jira as a tool should allow flexibility.

[Nic Brough -Adaptavist-]

No, you've missed the point again.  Multiple assignees is not the way to address what you're talking about here.  

I have yet to encounter any place where multiple assignees does not cause problems.  I've had this discussion many times here on the community, and on one of the longest discussions from years back, I've had three direct apologies and two pieces of work come from people who were proponents until they saw the mess they'd made with it.

Having a tool that allows you do something bad is one thing, where you just have to hope the end-user simply never uses the function.  But if you don't have to enable it, why should you?

[Jose Beneyto]

Supply and demand.

I don't think a client didn't get the point. Explain it however you want, but IMHO it is a lack due to the design of Jira.

To be clear. In the end, when your clients have to workaround your products, it is that your product does not fit them 100% and it depends on how necessary it is, they will end up leaving.

I have worked with multiple assignees for years in several companies with no problems. You cannot say that a thing does not work based only on your experiences. You do not have the absolute truth and it is only a subjective position. Mine is totally the opposite.
For me the thing is very clear. At the moment I have no problems with doing a workaround. With Jira I have other advantages, but if the deficiencies become important then I would stop using it

[Navneet Nair]

I had posted this comment when I decided to use Jira to track my team's progress. Over the years, folks in my team have stopped using it and we have found other ways to track work. Goes to show that if you don't care for your customers, your customers stop caring about you. No matter how 'pure' your philosophies are!

[Joe Pitt]

This is the design of JIRA. I don't see them ever changing it. I've been working with JIRA since 2006 and people were complaining about it then. Frankly if this is so painful an issue you should pick another tool.

[Joe Pitt]

Someone is always ultimately responsible for an issue even if a team is working it and that should be the assignee.

[Silviu Marian]

How do you let them both log time on it?

To really be honest I have never had this issue of not knowing who was responsable for what. Even if 2 people had the same task assigned to them.There is usally a lead that assumes the respnsability and has better knowledge of the task even if it branches off to several other people.

Therefore I would like this feature added in Jira Agile! :)

--------------------------------

Yes but how do I track the the time that those 2 or 3 people spent on the same task? I duplicate the task right?

[Nic Brough -Adaptavist-]

No, let them both log time on it. Doesn't matter if it only has one assignee.

(And I agree with Joe - it's actually critical that an issue has a single responsible person. Think of the basics: "It went bang, who do I shout at?". With more than one assignee, people start ducking. And you get "I thought X was working on it". You have to be clear that it's a single person)

[Jetalkumar Desai]

Unfortunately, Atlassian does not aware of agile best practices and team dynamics. As Atlassian user, you have to be always rely on your own automation and external plugin as they are clueless on customer expectation.

Just use custom field called collaborator with multiple assignee and track.

Thanks 

[Nic Brough -Adaptavist-]

Unfortunately, having a single assignee is best practice, Agile or not.

You should never have two assignees for an issue, it does not work in real life.  Look up the bystander effect if you are under the misconception that multiple assignees work.

[vpossoz]

Sorry to let you know but you are wrong and pretty opinionated.

Having two people on the same task works perfectly well in real life. Obviously, you have never practised pair programming so here's a link about it:
 
https://en.wikipedia.org/wiki/Pair_programming#:~:text=Pair%20programming%20is%20an%20agile,two%20programmers%20switch%20roles%20frequently.

[Nic Brough -Adaptavist-]

Nope.  You have not read (or understood) the earlier posts about pair programming - the assignee is not the same as "the people paired up"

Is there any chance you could read and digest all the earlier posting about this.

Or, give us an explanation of how you can allow more than one assignee without the possibility of one of them being able to say "I though someone else was dealing with it so I did nothing"?

If you can't solve for that, then you have to admit that you should not have multiple assignees. 

[Elena Ashley]

Truthfully if you are a "pair programmer" type of shop, you need to be able to assign both people to the issue and they should both have it on their board, record their comments and their time. Esp when dealing with branches (from bitbucket integration). It is a real hassle to have to set up a "team" of every pair programming team you have to assign to an issue. How have others worked this?  Any plugins? 

[Ross Curtin]

Agree Elena Ashley,   And nearly every other tool allows you to have multiple assignees and multiple owners...the reason...agile teams...scrum teams have a montra - no one is done all are done...and stories as a construct are complete Design build  test cycles with multiple contributors; therefore,  multiple team members could be assigned to a Feature, or a Story or even a task due the Agile XP practices where two or more people pair up on the task...All of these are good reasons to add this feature... other tools allow this and have for years...

[Nic Brough -Adaptavist-]

So have you ever worked in a place that uses software that allows multiple assignees?  If you have, you will have seen a lot of "I thought someone else was working on it".  Which is, of course, a complete failure.

[Joe Pitt]

Instead of beating your head against the wall pick one of the workarounds listed in previous posts. It is easy to add a custom user picker field that allows multiple users. Or switch tools. 

[Sergio Luis]

@Nic Brough -Adaptavist-I have been working with programming in pairs for a few years and this problem never occurs. It's a working duo, so the two people (or more in the case of "Code Deep Dive") are responsible for bringing the status of what's going on with the task.

I understand that it is a question of team culture and maturity and that more mature teams do not face this type of problem, dealing well with the division of responsibilities.

Pair Programming is one of the practices in the agile world. I understand that since the jira aims to be a tool for controlling agile processes, it should take these scenarios into account.

[Nic Brough -Adaptavist-]

Pair programming is the exception where it works fine.  But it's also a case where you don't need to worry about it.  You've worked so closely together as part of the pair, it doesn't matter which one of you is named and hence asked about it.  Jira lets pair-programmers down because there's only one assignee, but it's really not that hard to add a field for "other half of pair".

In the other 99.9% of cases, my 25 years of watching the <really bad word deleted and replaced with> mess made by "I thought one of the other assignees was responsible" tells me that it simply does not work.

Can you give be an example of where "I thought someone else was doing it" is an acceptable or positive reason for failure?

[Chris P]

Sounds like your company is more focused on figuring out who to blame instead of focusing on the solution. I've never had an issue with having a partner assigned to a task with me.

[vpossoz]

For those who disagree with @Nic Brough -Adaptavist-  and need to assign 2 people to an issue, did you know that Portfolio allows you to assign several people to an issue? See here: https://www.atlassian.com/software/jira/portfolio

How wonderful if this could applied to the taskboard! - I don't need anything more, and the backend already supports it!

Please Atlassian stop listen to naysayers and let those who need it assign 2 users to issues on the taskboard.

[Sergio Luis]

@Nic Brough -Adaptavist- This scenario that you bring to us, exist. I'm not desagreing with you, it's really bad if this occours.
But it's not a tool responsability avoid this. It's a culture or process problem, that should be fixed by leaders day by day

We have many companies and teams that has maturity enought to work really well with many persons working in the same task or history. Has a tool, I think Jira should garantee both scenarios, configurable if it's the case, that way the Jira Admin, based on your team maturity can choose what is better.

[Nic Brough -Adaptavist-]

@Chris P  - absolutely the opposite.  I work for a company that doesn't do "blame".  We get stuff wrong, yes.  We don't blame people for getting it wrong, because we don't need to - when we get it wrong, we say so, not wait for others to say so.

For the "need" to assign more than one person to a task, the answer is still "this is wrong".

If you disagree with this, then please provide a scenario where it will not fail - show me an issue with two or more assignees where none of them can say "I thought one of the other assignees was responsible"

[Chris P]

@Nic Brough -Adaptavist-  Your questions are centered around who to blame so imagine my confusion when you ask me again about how I would handle a scenario where I need to figure out who gets the blame for poorly communicating with your partner. 

It just doesn't come up very often. If it does, someone just owns the problem and solves it. What we don't do is blame a tool for providing basic functionality.

I hadn't realized this thread was many years old. This doesn't seem productive. We'll just agree to disagree and move on.

[Nic Brough -Adaptavist-]

@Chris P  - my questions are centred around working together.  Could you move towards that instead of insulting people who point out that you're wrong?

[Quadri Sulaiman]

Just click on your Issue,

Click the Action Button (Three dots beside Share Icon),  

Click Configure,

Add a People Field and Change the Name to Whatever you like (e.g "Assign More") 

Problem Solved.

[Manish Chacko]

I don't have the Action Button (I'm not an admin). Also, my company will not create new custom fields!! If it were that easy, I wouldn't waste time on here.. We're evaluating Planview LeanKit that not only allows multiple assignees, it also tracks related issues with an arrow and turns blocked items red when blocking item is past due.

[Aswin Achuthan]

We can create "Secondary Assignee" custom field and add another user to that.

Also, configure workflow post conditions to send notifications for the user in "Secondary Assignee" field.

Even though it is not the perfect answer you might be looking for, but if you have ScriptRunner or Automation for JIRA plugin, there are a lot of features you can do with this.

Thanks,

Aswin

[Pravin Awati]

Thanks 

[Onkar Ahire]

Continue... with Paul answer

4. Multi User Picker as Multiple Assignee custom field or custom field "group picker".

Regards
Onkar Ahire

[RambanamP]

i dont thing it is posiible to assigne one task to multiple user but work around you can do this

check the this document

https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users

some more help you can get from here

https://answers.atlassian.com/questions/129295/assign-a-task-to-multiple-assignees

some onle already issue raised with atlassian here

https://jira.atlassian.com/browse/JRA-1397

[Nic Brough -Adaptavist-]

Absolutely right, the assignee is a single user field and you simply can NOT assign an issue to more than one person.

This is by design and the request to "fix" it is rightly closed. The other two links Rambanam gives you are pretty much the best ways to indicate you've got more than one person with current responsibility for an issue.

[IshanL]

May be you can other use as an watcher