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
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!
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'.
Don't tell your users what they need to do, let them choose how they want to do it!
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.
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.
So when someone says "who's working on it?" and both of them say "the other one", you have a broken process.
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.
We also desperately need this feature! This is a very limited way of thinking that the tasks assigned to several people can be overlooked. Maybe in some average situations. Then why all other parts of JIRA are so flexible, and this tiny little detail - not? Double standards, huh?
@Tatjana Domnina: I agree wholeheartedly. What @Nic Brough [Adaptavist] is saying, is that because he's seen a real-world problem with a feature, everyone should be denied it. It's like saying because eating too much red meat causes cancer, nobody should be able to eat red meat.
Yes, I am, except you're de-emphasising the scale of the problem.
I'm not saying "because I've seen a real-world problem", I'm saying "Everyone has seen this problem". A better analogy would be more like "we know eating too many foxgloves kills everyone who does it, so let's not sell it as food in all our supermarkets".
Yeah possibly we both picked bad examples. You are making the same mistake as me. You are over-emphasizing the problem. Your analogy is incorrect, too.
I think there are legitimate reasons for having this feature, but you just won't admit / see it.
I've been part of this conversation for quite a long time now. Multiple assignees is useful, but I think Nic and I agree that the only context it makes sense is when you have people pairing up/swarming and use JIRA Agile as a direct replacement for your physical board.
If it doesn't satisfy that situation then you should never have multiple people assigned to a single task as they can't all possibly be doing the same thing, you need to make the tickets more granular.
Pairing doesn't fit in to this criteria as you have two people working on one ticket with only one person writing code at a time. They may take it in turns who the "driver" is, they are both working on the backlog item, but only one is actually entering code via the keyboard (they could both be classed as writing code, but that will be verbally rather than into an IDE).
It's been discussed at length above. No-one has yet come up with a scenario where multiple assignees cannot go wrong. No, I've not done an exhaustive survey, I just speak from decades of experience in several fields, which is that everywhere that allows multiple assignees has had problems with it.
Everyone here who has said "well it works for us" has been unable to show me that it cannot be a problem for them. One, who shall remain nameless, I happened to end up working with recently, and despite their stance here, it really did turn out that they were in a complete mess with users unsure who owned an issue when there was more than one assignee.
In short, why allow people to make a mess when you don't have to, and you don't need to?
I should also emphasise it's just the assignee that matters. Who is the currently responsible person? You should never allow a state where a group people can say "but I thought the other one was responsible". Because in real life, it happens. And a lot more than people think it does.
By all means have other fields for "other interested people", "person who will do dev, 2nd person for test, 3rd for authorisation, etc", "group that owns this issue in general", and so-on. It's just the single "who is responsible at this point" field that I've been talking about.
Nic Brough [Adaptavist] When a person starts his/her speech with "Everyone..." or "Everywhere..." I can't take it seriously. There are always exceptions.
Meanwhile, I found a way how to add more people to a single issue. Used a custom field User Picker (multiple users) and named it Pair-programmer. This workaround took 1 hour of my precious time
Image 09-01-2017 15-26.png
Nice one Tatjana, I hadn't seen that field before
NicI think you have to accept that if a team is following XP practices that there can be two people who are equally responsible for a backlog item. This sort of thing could be a switchable feature, much like the KanBan backlog is. If teams don't want to run it, or they find that it is being abused, then you can disable it.
When someone says always, I say the same thing.
I think this is the only conversation where I've ever repeatedly said Everyone. Because, I really do mean it. Everywhere I've seen multiple owners of an issue, an "I thought someone else was responsible for it" event has occurred.
Glad you've found the associated-person function, there's nothing wrong with that at all, it was brought up in the original discussion. (Both the pair-programming and ways to have another user included subjects)
@Tatjana Domnina Wow, brilliant! I think that will work out in my case.
@Nic Brough [Adaptavist]
Everywhere I've seen multiple owners of an issue, an "I thought someone else was responsible for it" event has occurred.
Hm, I don't agree with your point. I'm looking for multiassignee feature because there's an opposite thing: tasks are assigned and prioritized to a person, and in case of one assignee might be fall out of the scope of other team members. This happens just because our JIRA board configuration might be not really comfortable for the team to see the tasks they might participate in. And I'm looking for the way to do it.
We don't have "I thought someone else was responsible for it" thing, so I think it's possible to refrain of using 'Everywhere' - my team is the example. My personal opinion, though it contradicts with what I have read here, is that product owner (who is actually creates Stories and defines business formulation of the problem as an issues in JIRA Backlog) MUST NOT choose the lead (the only assignee) and he/she can't actually - this is done by team members. However, Product owner may assign a team.
But when team structure is not fixed, the 'custom account' approach is not useful. So this is why people looking for multiassignee option.
All mentioned points make JIRA Agile usage a bit uncomfortable - too many iterations to make the board to look like team want it to be (for current sprint).
I'd like to finish with a note. I'm really surprised of reaction to this.
People keeps telling - 'Hey, we as your users would like to have the multi-assignee feature', why don't just make a switch somewhere to make it enabled... Not the `hey, we have some crutches that maybe will help you.`, but something really good and useful. And still no outcome.
Why? In the end people will find the workaround, but most probably it won't look nice it will be different accross the teams. It would be hard to synchronize or integrate.
All of it just deliver the butthurt to any JIRA user...
Well, hope recent Trello acquisition might change something
I'm afraid you've missed every point made above, and I'm not going to repeat it all over yet again.
There is no need to implement a design that allows for bad things to happen, use a custom field to help with information about other users, and stop trying to shoot yourself in the foot.
@Tatjana Domnina, if you change the settings like you proposed, does the task also occur in the sprint board of the pair programmer? Because we're planning the Sprint with the help of the board and use the tasks to plan our free time. If a user is pair programmer and one doesn't see his task on the board, people might think he has more time than he really has.
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.
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
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.
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.
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.
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?"
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.
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)
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.
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!
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.
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.
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.
The roof is on FIRE… network outages, broken processes, upset clients and employees. Each day seemed to bring more and more issues. Incidents were communicated via email, messengers (skype or teams) ...
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