There are a few solutions for allowing multiple assignees to issues.
There is also a great article available here on a similar topic with some additional examples:
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...)?
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.
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. :(
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.
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.
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"?
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,
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.
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.
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?
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.
@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.
"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.
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.
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?
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
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!
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?
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)
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.
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:
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.
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?
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_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.
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?
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.
@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.
@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"
@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.
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.
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.
i dont thing it is posiible to assigne one task to multiple user but work around you can do this
check the this document
some more help you can get from here
some onle already issue raised with atlassian here
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events