How to assign an issue to multiple assignees

[Ramya Pendem]

Hi I am Ramya. I am new to JIRA. Please advise me how to assign an issue to multiple assignees.

[Vik Chopra]

The ability to assign multiple task owners should be added to Jira, agile scrum at a minimum.

Collaboration is enshrined in both the agile manifesto and scrum guide and part of the DNA.. shared understanding, shared ownership, the best ideas come from developers and the business people working together daily, and the list goes on.

Shared ownership is a good thing! Beyond the active build stage, shared ownership can also be seen as shared recognition when a piece launches. 

This would also enable stakeholders to have contingency or backup for a POC or if the previous task lead left the company.

In other applications where scrum is used for example Creative, it would be very beneficial for a landing page for eg. to be lead by both a writer and a designer. It feels like Jira is pushing a hierarchical approach.

Gotta respect the core agile principles and values if you expect people to use a product that labels itself "agile" & "scrum" prominently.

If it fundamentally or theoretically contradicts with something, why not just add it as an a settings toggle? There are settings for a million other things in there already!

[Nic Brough -Adaptavist-]

I think you've completely missed the point here. 

This sentence says it all:  "In other applications where scrum is used for example Creative, it would be very beneficial for a landing page for eg. to be lead by both a writer and a designer."

Scrum says nothing about assignee, in fact, in your example, it directly says that you should not have a story that is "lead by a writer and a designer".  The story is the responsibility of the development team.  Not one or many individuals within it, the team is responsible.  (And you know who the team is because the issue is in their backlog or on their sprint board)

[Vik Chopra]

@Nic Brough why would Jira agile scrum have assignees at all then? In your thinking, each ticket would just be assigned to "Team" and this is absolutely not the case. Jira offers assignees, but only one.

There's tactical value in having multiple assignees noted in my original comment and fundamentally, you and jira overlook the tactical value owning something together.

This feature would foster better teamwork, especially in the more work-from-home world we now live in.

And remember, scrum is getting more widely used (applied) across various industries. If Atlassian expects its software will stand the test of time over the long-term then it should inspect and adapt based on what customers are asking for. That also is a key piece Atlassian is overlooking here - Give value to your customers, not your internal, theoretical, software-only myopic view holders.

[Nic Brough -Adaptavist-]

You're right, Scrum doesn't need assignees at all, and we often find (healthy) scrum teams drop the field.

Jira offers a single assignee by design, and has done for a long time before any boards for supporting Scrum and Kanban were implemented in it.

It is designed that way because you should never never have multiple assignees.  In all industries, in real life, multiple assignee does not work.

I've spent years sorting out the messes made by people implementing mulltiple assignees, and in some cases, this has been done by migrating away from systems that allow it on to more sane systems (including Jira) that explicitly do not allow it.

[Kristian Patlevic]

In many teams, pair programming is a thing and working on a bug in a pair is also helpful - also let's say there is a novice in the team and he need a help in the first two months with the tasks - with your logic in the board there should be task assigned to the new boy and a separate task assigned to the one, who's helping him.

In which scenario does that make logic to you and is more transparent? All you add is stupid excessively complicated administrative procedure to do simple thing.

So you should have multiple assigners, in some industries, in real life, multiple assignee does work.

[Nic Brough -Adaptavist-]

You don't need multiple assignees in pair programming either, the people doing it will have worked so closely together, it doesn't matter which one you assign it to.  And you can simply add a field for "other part of pair" if you really really need it.

In all other cases, multiple assignees will let you down.  It is of no use in real life, and I can guarantee you it will cause you problems.

[Nic Brough -Adaptavist-]

There's no point in repeatedly making false assertions while ignoring the main point.

Multiple assignee does not work.  It is not implemented in Jira because it does not work.  That's all. 

[Elifcan Cakmak]

Hello,

You cannot assign one issue to multiple assignees. It is an impossible thing to do in Jira. Because this is against the principle of how Jira operates. If you assign one issue to multiple people, the responsibility of the issue will be vague and not clear. That's why you cannot do it.

However if it's very crucial, you can create optional configurations. For example, you can create a mail group that consists a group of people, create a user with this mail group on Jira and assign the issue to this user. But I would not recommend such a thing because of the reason I explained above. 

If you explain the business reason why you want this, maybe we can find another solution that would fit your needs.

Regards.

[Ramya Pendem]

As a tester I assign an issue to the developer and I would like to send the status of the issue to my TL and PM also as a notification.Please suggest.

Regards,

Ramya

[Elifcan Cakmak]

Hi,

As @Sloan N_ B_ suggested below, you can use watchers feature of Jira. Check out this blog post about watchers and mentions. If you want your TL and PM to get notification every time the issue is updated you can use watchers. If you want them to get one time notification you can use mentions. 

https://www.atlassian.com/blog/jira-software/using-watchers-and-mentions-effectively

Other than that you can create issue filters for more than one issue and other people can subscribe to these filters to get timely notifications that you manage.

https://confluence.atlassian.com/jira064/receiving-search-results-via-email-720416706.html

Regards.

[Ramya Pendem]

Hi,

Thank you for your support.

I am not able to understand from the above information.Could you please explain me step by step how to create watchers .

Regards,

Ramya

[Sloan N_ B_]

See this blogpost https://www.atlassian.com/blog/jira-software/using-watchers-and-mentions-effectively 

[Susie Najera]

Has there been any movement on this? The participants and watchers are great if you are keeping an eye on certain issues. However, sometimes multiple tecnicians work together on the same project/task and it takes several hours to complete-- this only allows time credit due to one technician for that task. 

If anyone else is also concerned about this-- I have suggested the techs to link tickets to the original request in order to record their time working on an issue. Of course, this woudl only apply to longer projects.

However, it would be great to have multiple assignees as an option so that the "Linked" tickets don't bring up the ticket count.

Thank you

[Nic Brough -Adaptavist-]

There is no movement to be made - you do not want multiple-assignees and Atlassian are not going to implement it, they closed all the requests with "won't do".

[G Morrow]

What Nic said, when you assign a ticket to a technician that person becomes responsible for it (open to close) which is the principle that is reinforced in JIRA.  If you have someone helping them, you could create a sub-task of that main ticket and assign that to the helper and put all their work/time on that sub-task which stays under the main task.

[Jan Steinke]

This entire argument neglects the fact that pair programming is a widely spread practice and JIRA basically becomes useless in tracking the pair currently working on a ticket. I hope Atlassian reconsiders their 20th century opinion on this topic

[Nic Brough -Adaptavist-]

That's the one tiny edge-case where it has a valid use case.  But the nature of pair programming makes it pretty much useless - it doesn't matter which one of the pair it is assigned to, and if you really desperately need to record both, add a select list for "other person"

I don't think anyone would want to open up software for vast misuse just for one edge case that has a simple way to "fix"

[Jan Steinke]

Teams are misusing Jira already on a daily basis, I don't think throwing sticks between the legs of people who have legitimate use-cases for a feature is helping anyone. We now just use Github Projects for my team. We have GH anyways and it allows us to properly visualise the pairs on the board. I just wanted to share that Atlassian is actively losing customers over this while the rest of the industry is moving on and focuses on enabling teams instead of blocking them. This "other person" fix is also hardly a fix at all. It's basically a useless feature which doesn't even show up on the board but is merely helpful for reporting cases which is a misuse of Jira, IMO.

[Nic Brough -Adaptavist-]

I think it's better to "stop people breaking stuff for the vast majority of usage" and accept that "a tiny handful of users have a minor inconvenience of having to look in two fields on the rare time it matters" is a better compromise.

"Single point of responsibility for an issue" is actually something that crops up more than you are thinking, and because Jira does it properly, it helps get it selected as the replacement for the broken system that allows it.  Although I can't complain too much - "sorting out the mess made by allowing multiple assignees" has generated quite a lot of work (including migrations to Jira) in the past.

I do not think it is possible to find any justification for "we're perfectly happy to let people use 'I thought someone else was doing it' as a valid excuse for failure to deliver".

The "other person field" is less than ideal, but like I said, it's a tiny handful of people that use it.  What I often see for pair-programming is "assignee = the pair's team-lead or boss, with a multi-select field for the two in the pair", because that's often a more useful point of responsibility.

[Jan Steinke]

I think the take away for me is that Jira optimises for corporate environments where hierarchy and control matters more over self-organised teams where visibility inside the team and trust in a flat hierarchy is a given.

[G Morrow]

I'm not sure that is a correct view to be honest. You still have the ability to visually see everything and assign work to anyone you want. In addition, you can create sub-tasks that serve the same function for "tracking time" but keeps it all under the main task.  I can see where in some teams having multiple people working on something is good but there are ways to still track the work both overall and individually.

[Nic Brough -Adaptavist-]

I don't think it's quite right either.

A self-organised team, from the outside, no, doesn't technically need an assignee on an issue.  You could argue "the whole team is responsible", and that's fine for well-functioning self-organised teams.  Internally, though, if a team is not working perfectly, how do you stop "I thought someone else was working on it?".   Single assignee is the only option.  And it protects the team from "well that team won't tell me what's going wrong" and "I need to know who is responsible for..." at the corporate level.

Jira is highly optimised for self-organised teams.  "Multiple assignee" is optimised for multi-level failures and nothing else.

[Jim Schmidt]

Meh - a team not working perfectly could just as easily have problems with individual assignment. "It's assigned to me but I am not working on it and have nothing to do with it"

Or, "we don't know who to assign it to so we'll put it in this unassigned bucket that no one cares about"

In many cases there is shared responsibility on our tickets, and any one in the shared responsibility group can speak for the ticket.

[Nic Brough -Adaptavist-]

Yep, but the point there is a well-functioning team won't need to pay much attention to an assignee field.  They certainly won't even begin to think they want a multiple-assignee field.  Team ownership of issues would be done elsewhere (for example "it's on our board")

[Jim Schmidt]

Not so. For example we like to count capex hours per person. So several people assigned to one ticket would be a nice possibility.

Two people moving a piano - why does one have to be assigned to the ticket when both workers are doing the work? It's sort of nonsense to me the idea that the piano can't be moved otherwise.

[Nic Brough -Adaptavist-]

See above - you don't measure expenditure by assignees, the most obvious thing to do is measure it by actual work logged (you don't have to be the single point of ownership to log work on something)

And for the piano - "I thought the other one was doing it".  That is the monumental nightmare that multiple assignee lands you in, and any halfway decent process demands you never do that (also as repeatedly explained before)

[Jim Schmidt]

I disagree and so do many others.

The Jira log work mechanism adds hours to the current assignee.

A group design review can very well be represented as a task. It has many people. The process isn't indecent just because there's no sense in tagging some arbitrary person of the group as an assignee.

Similarly there are times when many people are investigating a high pri issue together. There's no sense in making a ticket for each of them.

There are times when there is individual responsibility for a ticket, and there are other times when groups collectively share responsibility.

[Nic Brough -Adaptavist-]

Nope, Jira work logs are added to issues by separate people, irrespective of the assignee.  You may have configured yours with permissions that say "only assignee can log work", but that's absolutely not the defualt.

Your example fits perfectly into all the stuff discussed above.  I'm not going to repeat it again as you choose to ignore the main point - "I thought someone else was doing it".

[Jim Schmidt]

Susie (above) isn't concerned about the risk of "I thought someone else was doing it" and neither am I.

I landed here because folks I work with had asked me if Jira would ever support multiple assignees, and, like Susie, was hoping there was a solution or progress towards one.

The answer is clearly 'no' but the rationale looks more like it got designed into a corner, than a real reason.

[Nic Brough -Adaptavist-]

The rationale is to prevent people getting into a mess with "I thought someone else was doing it".  It's an anti-pattern, it's a disaster in most places (in some heavily regulated fields, it's even illegal, with good reason).

So, yes, you've found your answer - Jira doesn't do multiple assignees, never will directly, but does have lots of way to do "and these other people/teams/things may be involved", and Atlassian are actively improving on those.

[Jan Steinke]

It's funny how you mention that the time logging is configurable but the assignee is not. It feels like all arguments could be applied to both features. Why is the time logging configurable, but the assignee is not? Fair enough if some airline company or financial company has regulations coming in from above but most digital companies _do not_ operate in such a highly regulated area. Why does some food delivery or furniture company have to obey to the limitations of those regulated industries? Why can't this be configurable?

The whole argument _does_ sound like what Jim was saying:

>The answer is clearly 'no' but the rationale looks more like it got designed into a corner, than a real reason.

The product was designed around this and it would not be possible to change Jira in this regard and the whole "ambiguous responsibility" argument is simply a straw man.

[Nic Brough -Adaptavist-]

>It's funny how you mention that the time logging is configurable but the assignee is not. It feels like all arguments could be applied to both features. Why is the time logging configurable, but the assignee is not? 

Time logging and responsibility for an issue are two totally different things, with different purposes and reasons for existing.  Comparing them in the context of this discussion is not relevant.

>the whole "ambiguous responsibility" argument is simply a straw man

That statement there is a straw man - you are now misrepresenting the core of what is being said - multiple assignees does not work (for many reasons, the main one being it allows "I thought someone else was doing it")

[Sloan N_ B_]

Hi @Ramya Pendem

@Elifcan Cakmak is totally right, this is a thing against Jira's principles. 

Work instead with watchers or if working with Jira Service Desk with request participants.

Cheers
Niklas