Multi Assignee Field for issue in Jira

[Nayeemuddin Khan]

I have come across this need of the time from my multiple Project teams as well as from different organization across the world for a multi assignee field for an Issue, even though, be for team managed project at least. The proponents argue that in today`s agile world to save time, a single issue needs to be worked by multiple users to complete in less time. That's what it's happening in multiple organization across world. The opponents argue that there will be difficulties in tracking the real work, if assigned to multiple assignees and also there is chances of ownership issue. Nevertheless, they also are convinced that a single issue needs to be worked by multiple users to save time in this fast-paced agile world. However, as multiassignee field is not currently available in JIRA, there is no way to capture the real work from different assignee for that issue or project to say. 

Many of our elite community members have suggested an out of box work around for this to use a Customized field with multiuser picker/ Group picker. This may work for small or few projects. But in real practical world, this may not be a solution. I urge Atlassian to consider this in their next upgrade and also request our community gurus for a better work around for today`s agile development environment.

Please do share your thoughts and ideas on this. Will love to know them. Thanks.

[Nic Brough -Adaptavist-]

>a single issue needs to be worked by multiple users

That seems to be the crux of your question, and your "solution" is, I am sorry to say, wrong.

Never have an issue that is assigned to more than one person.  If you allow for that, you're simply allowing it to go wrong.  The assignee is the one single person responsible for getting it done.  One of the reasons Jira was written was that the systems people were using 20 years ago were going wrong because they allowed multiple assignees.

Multiple assignees fail.  In every case.  Do not do it, it's one of the three things that will guarantee project failure.

There is, of course, nothing wrong with having other people involved in an issue.  When I am on holiday, I expect the rest of my team to pick up queries on my open issues.  Primitive ways to do that are usually by adding a group or team field, but the best way way to do it is by being a bit agile - have each of your teams have a board to work from, and have them work on "it belongs to our team when it is on our board"

[Walter Buggenhout]

@Nayeemuddin Khan,

This is more a discussion topic than a question. You list the options and workarounds pretty well as far as Jira as a tool is concerned and I don't expect any changes there, to be honest.

The assignee in Jira is indeed a single user field. It is the person who owns the ticket right now, as we look at it. There can be multiple owners of an issue, but not simultaneously. If tomorrow someone else takes over the ownership (because of a status change, because of the previous owner is out of the office or whatever reason), nothing stops you from changing the assignee/owner on the ticket. But you still know who to talk to about the issue just by looking at this one field.

If you say multiple people are working on the same issue, that either means this is a large body of work or a duo is working on it as a pair (pair programming). If the first example is a story or a task, then this is probably an indication that you have not defined your work at a granular enough level. Working for too long on a single task with multiple people will not show progress, leads very likely to multitasking and slow feedback loops, which is all not very agile.

It may happen at epic, feature, initiative, ... level that multiple people or even teams are involved. But those are not the issues that are actually being worked on. They create the bigger context. At those levels it is very common to specify the various people / roles / stakeholders involved, but then it does make sense to specify them in separate fields corresponding with their actual roles. You can use the RACI / DACI models for those or approach this more traditionally, by specifying the business owner, sponsor, PM, developers, etc.

I know this is not a yes/no, 👍/👎 but hope it helps!

[Nayeemuddin Khan]

Very True. this is a discussion topic, needs more deep analysis.

Also, as this is based on need from certain teams on an emergency situation, this is not going to be a standard for everyone. Thirdly, we are talking about an issue, may be a break fix one, which require lots of attention and immediate fix. We know multiple teams work on such issue at the same time and many a times its NOT CLEAR WHICH TEAM SHOULD OWN IT< RATHER MULTIPLE TEAMS ARE ON IT. for example, an issue with a Firewall config setup, requires Infrastructure, Network, Security, Compliance and other team to fix it. Instead of waiting to finalize who owns, start working on it immediately to fix it. All multiple team can jump on it and work to fix it. Thats the need of the time. 

[Nic Brough -Adaptavist-]

But who is the one person responsible for getting it done?

Multiple assignees means you can't know.

So, when different people need to work together on a story, sub-task it, or create linked issues for each person to take responsibility for.

[Walter Buggenhout]

In an emergency situation, it is quite common to open a war room (that may be a dedicated Slack channel or sometimes, when you're working co-located even a physical meeting room) where you allow people to communicate amongst each other about the issue. Bringing people together to solve a really big problem is usually a very good idea.

But: each from their own expertise and with their clearly defined part of the puzzle. Transparency is golden, but clear ownership is golden too. It is not a good idea to mix these things up. When an issue in Jira is created, it is (or should be) clearly defined. Investigating a big problem usually leads to possible assumptions that need to be validated by doing something. Jira helps you coordinating that by:

• defining what needs to be done
• indicating who needs to do this
• creating transparency about progress through status and comments

If a big problem needs effort from multiple teams, define those to do's separately indeed and make responsibilities clear. And indeed, share findings from the different teams involved through proper communication channels. Opsgenie's escalation policies and solutions like chatops and the incident command center approach may be the type of thing you need to support your scenario.

[David Berclaz _Apwide_]

Hi @Nayeemuddin Khan

If several users have to work in parallel on the same task, why not using Sub-tasks?

Cheers,

David

[Nayeemuddin Khan]

Great suggestions and thoughts for this. However, the question is not about the standard or best practice. Here, is a situation where multiple people are working or being assigned to a single issue. I am not saying this is the best thing, rather this is a requirement from a few teams based on their need. We may say this is the future Agile. whatever may be, SUBTASK is a good option, but the project team want to give each individual equal weightage for their contribution and assign to multiple people the same issue. 

[Nic Brough -Adaptavist-]

It doesn't matter that we're talking about best or standard practice.  The point is that multiple assignees for an issue simply does not work, ever, and hence the software does not support it.  

But it does support teams fine.

• One of the things sub-tasks are for is breaking up stories so that fragments can be assigned to different people, while retaining the overall single point of contact and responsibility being the single assignee of the story.  The sub-task assignees don't need to be part of the same team, but usually are.  And the assignee of the main story has a single person to talk to about the sub-task who can't say "I thought someone else was looking at it"
• Atlassian don't say it a lot in the docs, but you should be broadly working on the principle that "Board = Team".  Most teams have a primary board where they work together.  Obviously, more people can see it, the team a board represents is only the people who will work on issues within it.  (Heck, if you use Jira Align, you'll find there's no way to represent a team other than "the people working from a board")
• Service Desk projects don't necessarily have a board, they are of less use when you're "drinking from the firehose", but you can think of the default queue as the team.  Anyone who is going to pick up items from the main queue and resolve it is in the team.

The requirement from teams is not to make a mess with multiple assignees, it is to be able to identify that the team owns the work.  Do that with projects, boards, queues, or if you really can't get people to grasp that, use a field to explicitly state it.  (My favourite way of doing it with a field is to not ask anyone to fill in a field, but have a scripted team field that works it out from the issue data like assignee, project, queue, board, component, label, etc)

[Tim Perrault]

Hi @Nayeemuddin Khan 

Why not have a main task that is broken out into sub-tasks that can be assigned to individuals? In my company we do have dummy accounts that are created with distribution lists so on creation a ticket will be assigned to the dummy account notifying the whole team, but once an individual from the team assigns it to themselves, they will be doing the work.

I don't really see the benefit of having multiple assignees. A task with multiple subtasks is the way I would go if the ticket requires multiple steps and users.

Tim

[Nayeemuddin Khan]

This is a need from certain project team. We may see it irrelevant or nonbeneficial. but this is what is needed for that team.

[Tim Perrault]

Subtasks are essentially a big ticket broken down into different parts. These parts can be equal. This allows you to track not only the work, but also different statistics based on individuals.

Example: if one employee has too much work compared to the group, you can then assign someone else from the team to the subtask.

Another problem is tickets aren't updated in real time. Users have to "publish" their changes or comments. So what happens when two people are tackling the same problem without knowing?

To each their own I guess.

[Nic Brough -Adaptavist-]

>So what happens when two people are tackling the same problem without knowing?

Yes, that's exactly why you should not have multiple assignees.

The assignee is the person tackling that problem.  Whether other people are helping them or not is not important.  If someone takes up responsibility for fixing a problem, they should assign themselves to it, and once assigned, no-one else should pick it up.

In Jira, because there's no "real time" update that someone has been assigned an issue, you have to educate your users that a) always assign yourself if you want to work on it and b) before assigning it, refresh the screen, so you can tell no-one else has grabbed it.