Multiple assignees to issues

[Ivan Iliev]

I know this question has been asked many many times, and it's a mystery to me, why Atlassian won't listen to their users ???

Setting multiple assignees to an issue IS A MUST HAVE , when collaborating with other team members on a shared task !

I don't see a valid reason for this to be still "in consideration" phase, while a simple search shows hundreds of requests like this.

[John Funk]

Hi Ivan,

My short answer would be probably because not all users agree with the thought that a single issue should be assigned to multiple people. Just because some users want that functionality doesn't mean that all users (or even the majority of users) think that functionality is good business practice. 

So, there are work arounds as you have probably seen in other posts, but probably the easiest is to create a new custom group picker field or a custom multi user select picker field and use it to populate with multiple people or even a group for the issue. 

[Ivan Iliev]

Hi John,

Thanks for your answer.

However, I have to disagree with you.

I am sure you can see how this creates a burden for jira administrators to manage those extra custom groups , or custom fields , keep them up to date with team members, and maintain this in the long run.

Also, I think that if the functionality is well implemented, it wouldn't even be noticed by users not needing/wanting it. Let's take the watchers feature for example. You can totally have just one watcher of an issue and never bother to add more people to the watch list. Why not do the same with assignees ?? Nothing would essentially change for those users that still want to do the classic one-issue-one-assignee, but it would make huge difference for those in need of the feature...

[Nic Brough -Adaptavist-]

In my experience, this comes back to a simple question - "who is responsible for getting it done?".  In no project methodology is there any room for an answer of "I thought the other person was handling it".  It fails, every time.

In real life, you should never allow mutiple assignees.  It will lead you into a mess. No-one really "needs" it, they think they want it, but they almost certainly do not. 

(Exception - pair programming, but then people are working so closely together, it doesn't actually matter which one of the pair is named, the responsibility remains clear)

I've worked in places that have quoted "we need rid of multiple assignees (and Jira is the chosen software partly because it doesn't allow it)", and a lot more that have done it in some form and ended up getting me or colleagues in to help them get rid of it. 

So, all of that said, there is also absolutely nothing wrong with having "assigned to team/group" or "other people who might be involved" type fields alongside assignee (as assignee being the single person responsible for getting it done, they may be taking an advocacy or lead role in doing it, not actually doing it themselves).

And if you're being Agile, or even just doing support for an incoming stream of requests, I've seen a many ways of handling assignee single or multiple, broadly coming down to two things:

• Not assigning at all, the queue or board = the team.   The whole team takes equal responsibility (after all, they're talking to each other daily, so there's no real room for "I thought someone else was doing it")
• Automating it - set the assignee to the person who moved it to "in progress", as they're the one who picked it up to work on it.