It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Assign a task to multiple assignees

Viewing page 2 of 2

37 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

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.

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?

0 votes

I can't imagine any scenario where it's of use to other team members while it's in-progress with a pair.

0 votes

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"

0 votes

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?

My counter to that would be this:

On a physical board you would have two avatars and you'd pop them both against a backlog item. This is great as it helps non dev members of the team know who's working on what if they needs to speak to them about something (could be a PO with an update etc - we prefer to have this conversations in person rather than through comments in JIRA as it's more personal and builds a stronger relationship between team members).

It's also helpful to see how a day unfolds without asking people - at the standup someone may have said they were going to work on a specific backlog item and they start it, but then a colleague needs a hand with something so they go and pair with them, at which point they'd put their avatar on that backlog item and remove it from the other - now we can see what's going on without asking/interrupting.

A lot of teams complain about keeping JIRA up to date as well as a physical board so we tend to lean towards the JIRA board, but it's limiting in ways that are deeply frustrating like this - which leads to oft used phrase "I hate Jira"

In my experience all these things have been significantly easier if you use the entire Atlassian suite (from JIRA through to Bamboo and everything in between like Stash and Clover) as you can see who's been committing to what branches very easily and therefore don't have to do some of this other work.

0 votes

And, yet again, what happens when both of them think the other one is dealing with it?  It's fine to have multiple interested people, and your display would be a good move.  But multiple assignees always introduces the problem and your solution does not fix that.

I can't see how that situation would ever arise between a pair? Pairing is the only situation I'd ever imagine you need to have to assign multiple users to one backlog item.

I do completely support your argument that if it isn't pairing then multiple assignees are indicative of having backlog items that are too large and need to broken down.

0 votes

Sorry, yes, pairing is the exception, as you're working closely together.  But you still don't need multiple assignees for it in real life, because you're so close.  I like the idea of having a field for "other half" and displaying both avatars on the board.

Ah yes, we're refining this now! :wink: So I solutionised something and threw out everything I preach!


So here we go, the problem I'm trying to solve:

At the moment there is no way in JIRA to see if a ticket is being paired on or worked on by an individual team member. Pair's are not constant so being able to see the avatars of the team members working on a ticket would mean I could tell just by looking in JIRA rather than asking team members and appearing to micro manage.

We don't use the logging work feature on JIRA as it smacks of micromanaging by tracking the amount of time people are logging against a ticket.

Here is my use case for multiple assignees. I want to add a task that is a design review for the developers. Also, code reviews, documentation reviews, spike findings reviews, etc. This is how we keep the whole team up to date on knowledge of business rules, design, implementation and so on. In the future, I'd like to include QA. In our case that would be 9 folks. (I agree that our team is too big, but I have no control of that.) I want one task assigned to all 9 people, that allows all 9 people to individually log time to that task, that shows up in our daily standup as a task for each person, and that can be moved along in the workflow as a single task. It is important to management that we keep time logging accurate for each person. Now, I can to that with 9 separate tasks but, as you can imagine, that is very tedious and seems, to me, to be something for which Jira could provide some relief. If there is some other way to handle this in Jira with a single task that allows logging of time for mulitple users that I've missed then...I've missed it. I do think that it is valid to have team reviews that are a single task but cannot, in fact, be done by one individual. I wouldn't have a problem with an assignment of a "responsible" individual for the task but I really need capabilities mentioned above.

Again, if there is already a baked in way to deal with this then I aplogize for my ignorance.

Joe_Pitt Community Leader Jun 07, 2017

JIRA doesn't support it. They can self assign to log time and then reassign it to the 'responsible' person. 

There's nothing to stop people logging work and updating issues without being the assignee. 

And, as discussed before, there are plenty of ways of drawing many people into an issue. 

But you need a single point of ownership in real life, and JIRA only supports a single assignee.

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question


Community Events

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

Events near you