How can I assign single task to multipule assignees? I am struggling to find how I can do this.
This crops up so often, the workarounds are well documented. Even has it's own page (oddly, the first hit on <a famous search engine>) See https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users
I think this has been answered to death. Multiple assignees don't work in the real world because there's no clear responsibility. It can be very useful to have secondary assignees as well, but in reality you always want a single owner.
In the real world, multiple assignees does not work. Can you honestly tell me that you have never once had any situation where A and B are assigned something and one of them doesn't deal with it because the other one should have? Or have two assignees accidentally duplicate effort?You say "task owner" and "helper". That's really clear and useful. The task owner is the assignee. They own it, they need to deal with it, it's great that they have helpers, but you really have no use for many users here. The owner owns it. That's a very strong argument for not having multiple assignees. It's a very strong argument for having other fields that can help say "these people are involved/helping" too.Agile's "shared responsibility" is about the team working together to get stuff done. Part of that is being utterly clear about who is doing what, so that nothing gets dropped and no one wastes time duplicating the effort.
What is a search engine?
Assignee is a single person in JIRA. People use workarounds like creating a multi user picker fields and use it to store multiple assignees. You might also want to add that field in notifications so that they will be notified of any changes on the issue.
Google? Whats that?
Google maybe?
Thank you for your help. It was the most useful and a quick fix. Unfortunatly the search is not great if its not pre personalised from a previous search. Which is why I couldnt find a suitable solution.
This question is asked so often that it makes me wonder why JIRA doesn't allow its user base the functionality to assign multiple assignees to a task. My personal use case is where my team wont always work as a group or pair or "user account" grouping because they will dynamically choose tasks depending on the sprint. We work in an agile way and to reduce things in progress we will often have more than 1 developer/tester/etc working on a single task or sub task. In fact this type of dynamic team work is encouraged in an agile team. None of the workarounds allow for this properly. I'm genuinely astonished that the good people at Atlassian haven't just enabled multiple assignees by now!
Don't tell your users what they need to do, let them choose how they want to do it!
Agile talks about 'shared responsibility'. I note on my cards who is the task owner, as well as who is assisting that person to achieve the work. In my real world, multiple assignees are working very well. I hope JIRA can help me out here.
From a QA perspective at least, it makes sense to have multiple users assigned to a task/issue depending on the project and size of the team. Even then though, for JIRA purposes, we have have the 'primary' assignee which translates as the lead tester of the task/issue, who will coordinate/work with the 'secondary' assignees (using a custom multi-user field), fellow testers helping them. And then we have the watchers field for those who would like to keep an eye on the issue/task, yet not part of it. For team leads and managers, it helps them keep track of who is individually doing what without needing to create a new task or sub-task for each one of them, allowing them to have better fancy metrics with larger teams.
So, when you have two assignees, which one of them is ultimately responsible?
It does make sense to have many people who might need to work on it, in different roles, and people who are involved for various reasons. But more than one assignee fails.
And what about this scenario:
I give a task to two devs where I want that they do it together with pair programming. For example, a small task to create a simple service. Both are responsible and will execute at the same time.
I understand what you want to say Nic, but I already saw and can think in differents situations where we could have more than one responsible. I think this depends on the company's culture too. The pair or team can be 'ultimately responsible'.
I agree with Jeremy, David and Melanie...
Another scenario (maybe this scenario does not justify multiple assignees requirement):
Consider that the manager/leader/whatever uses the Agile board to check what is the actual task of each employee. This person looks in the 'In Progress' column of the board.
Employee A ask Employee B for help. It is a hard task and both know that they will spent more than one hour working together. Employee B can put his actual task back to 'To do / Waiting' and join Employee A task. Ok, in this scenario Employee A is responsible for the task. But JIRA users/administrators will need to create a custom field to see who is working on issues/tasks?
You could look how this works in Trello: it is easy (Employee B only needs to press spacebar hotkey in each task)
Sorry for the grammar, I hope this can help in the discussion.
So when someone says "who's working on it?" and both of them say "the other one", you have a broken process.
You've described another very good case for having participants or colleauges or helpers additionally named, but still no scenario where multiple assignees work in real lift.
Surely pair programming is a scenario "in real life" where you would benefit from having multiple assignees?
Also the point about 2 people thinking the other is working on a task breaking the process is just an indicator of poor communication between people, not a symptom of having multiple assignees on a single task.
There really is no point in arguing about this, people are clearly keen on this feature. I don't see the harm in giving users an additional option to choose from.
Again, pair programming is a good case for having associates. But still not multiple assignees - you'll be working close enough that the current assignee will always be able to tell anyone what the other is doing.>Also the point about 2 people thinking the other is working on a task breaking the process is just an indicator of poor communication between people, not a symptom of having multiple assignees on a single task.Yes, it is. Absolutely. It's also the case that it happens all the time. That's the whole point - allowing multiple assignees on a single task enables poor communication to become a problem. Every site I've been to that has multiple assignees has this problem to some extent, no matter how great they are at communication. There's no problem at sites that don't have it unless other things are broken (e.g. turning off notification or reporting on "you've been assigned x")
Anyway, yes, you are right, it's a pretty pointless discussion - Atlassian have stated that they won't do it, because it breaks in real life in all cases. I tend to agree with them, because I still can't see a single argument in this discussion where multiple assignees is a good idea that works in real life.
In the first scenario, they will answer: 'we'. Both are working on it together and both are responsible at the same time. They will start together at 1PM and finish together 6PM, for example.
For me, this makes sense in 'real life' too.
Sorry, I don't understand why this cannot happen and why in this example they would have a communication problem.
Right. So you don't need two assignees because they're working well together. You have the assignee as the single point of contact and responsibility, even though they're working with someone else. That scenario means you don't need multiple assignees, and my "who's working on it" problem doesn't exist. In real life, this isn't always the case though, and as soon as you drift away from the tight communication where you don't need many assignees, you're in a situation where you need a single assignee to be sure it is correctly owned.
You have the assignee as the single point of contact and responsibility
That scenario means you don't need multiple assignees
This is how you want to be or how you think it should work.
Could I (or others) have more than one point of contact and responsability? Because the way my company (or team) works is different the way you think it should be. You think people will have communication problems if there are two or more point of contact/responsible. Maybe not:
So you don't need two assignees because they're working well together
In real life, this isn't always the case though
It seems that you want to enforce this behavior because for you makes more sense or you never saw a dev process working good with more than one responsible, but it can work.
I think you're missing the point. In your organisation, you're communicating well - that's great. Because you're doing that well, you don't need multiple assignees In places where communication is less than ideal, you don't want multiple assignees because that allows things to go wrong.
In real life, there is still no case where multiple assignees are needed or useful.
Nic I like that you are so passionate about agile methodologies, but at this point I think you're going to have to accept that there are people in this thread that disagree with your opinions on this topic. It's pretty clear that the user feedback loop in this particular review session is weighted in favour of "please can I have multiple assignees in the next iteration?"
It's not about agile methodologies, I'm just trying to understand why people want this function when it really doesn't work (or isn't needed) in real life. Yes, that's an opinion, but it's based on many years of seeing multiple-assignees fail miserably and repeatedly. So far, no-one has given a scenario where it can work and be useful. I'm curious more than anything
Also, it's pretty moot - my opinion is simply echoing what Atlassian have said - it's not going to happen in the foreseeable future, because it breaks. See the original answer for some ways to include people without directly assigning them
In my experience, having multiple assignees has worked, and never seen or experience a situation it does not. The devs I am working with also been wondering how to keep track on JIRA of more than one person working on the same task, because that is their reality, that more one is needed, at which point they are equally responsible.
"So, when you have two assignees, which one of them is ultimately responsible?"
In the real life base scenario I described before, it is the one that is 'primary' assigned. Everyone else that are helping are 'secondary' assigned with a multi-field. In practice, the 'primary' assigned is responsible for updating and coordinating the task. With the same group, someone else becomes primary with another task. Manager then was keen in having rotating responsibility and developing everyone's skill in leading. Again, this was with a large QA team with a company that actively used JIRA for a lot of the communication and coordination. In my present position, I am helping gradually pushing for full integration of Jira/confluence use before we become a large team down the road.
Yes - that's exactly how most people do it and it works fine. You have one single assignee (primary) which changes over time, and then other people who are involved as secondaries. It's not multiple assignees, it's single assignee with others.
I have been on several projects at multiple companies with pair programming. there was no one single person responsible for any single card/task - both were. equally. It works just fine. The tools should support the actual process, not force a hybrid process for "kinda-agile" teams.
Pair programming is one of the cases where it might make sense in abstract terms. But, as you're working that closely together, it's unnecessary, so why break it for all the other cases where multiple assignees do not work in real life? (p.s. add a user picker for "partner" if you want to record the other half of the pair)
Sorry to bring that back from the dead but I don't agree with you on this one Nic - specifically with regards to pairing.
As a scrum master I have no desire to micromanage my team but it's good to understand if people are pairing on a ticket just from glancing at a board without having to interrupt them. The argument you keep making is regarding responsibility...well if two people have worked on it as a pair then they are jointly responsible for it, it's not down to one person in that instance.
You've still missed the point, sorry. Could you re-read the last comment? Where you should realise that while pairing is the one case where it's valid, it's also of no use, because you're paired, so it doesn't matter.
Actually I think it's you that's missed the point - it's useful to other team members. The JIRA Agile board is an information radiator to the rest of the team. Perhaps the best way to deal with it would be to have it as a switchable labs feature like Concurrent Sprints?
I can't imagine any scenario where it's of use to other team members while it's in-progress with a pair.
Not to sound belligerent, but it's not Atlassian's role to be the law on agile here. If having two people assigned to a task works for people, then they should listen to the market and provide the feature.
The point people are making above about the benefit of having a single point of responsibility is a bit misguided. Where this is a problem is where there is a big group of people responsible - the typical email to a big group for help doesn't work because everyone thinks everyone else is helping. This is where the status is not visible. The JIRA board serves as a the ultimate how-are-we-doing? Why hasn't this task moved at all? And having two people assigned to a task will not affect this at all. It's as easy to hold those two to account as it is the one.
Atlassian, come on, stop making excuses and sort this out please!
It's not really them trying to be the law, they've chosen not to implement something in their software. There are several ways of adding associated or interested people or groups, but the principle of a single user being the responsible party is the important one, and one that no-one arguing for multiple assignees here has yet managed to deal with
You say something that gets to the crux of it again.
>Why hasn't this task moved at all? And having two people assigned to a task will not affect this at all.
In real life (i.e. the last 20 years in software) every time I've been to a place which allows many assignees, there's always been a problem with two or more people named as the owner saying "I though the other one was responsible". Always. My current project has this problem, and one of the gains they're getting from moving to JIRA is that they won't be able to argue the assignee.In all the discussions above, not one useful solution has come out. Lots of yelling "it works here" and "of course it works", but no-one has managed to solve that problem without essentially saying "we need a single assignee"
The solution is the rest of agile. If you're saying it's a problem that a task is assigned to two people then your feedback loop is too long and I'd say you are not doing daily standups right and/or you are not reviewing your board as often as you should be (several times a day). Saying "I thought Jim was doing it", is frowned upon at my company, and should work at most once where ever you work. The point of having two people assigned is not that any one of those two people do the work, but that they work on it together!
And in my experience having small teams empowers people to take responsibility and run with tasks. I have a feeling you've worked with big-ish teams in the past where it is possible for people to hide behind the amount of work in the sprint.
In an ideal world, you work together well on things and you know who is ultimately responsible for an issue. In a lot of places that works fine, and people mostly ignore the assignee field because it's not important, because they know that the team is working together. There's no point in worrying about the field in those cases, and multiple assignees adds nothing to it.
But, if that breaks down (and I totally agree with you that in large teams or organisations, it's easier for a break down to happen), then you still end up with "I thought Jim was doing it". It's a bad thing when it happens, it's definitely frowned upon, so why not prevent it by having a single assignee?
It looks like you're new here. Sign in or register to get started.
![Photo of Jobin Kuruvilla [Adaptavist]](https://us.v-cdn.net/6038660/uploads/avatars/17/c4/n17c4b8c7de7da6cee02bd69e8a3b017b.png)
