Assign a task to multiple assignees

rawduk January 24, 2013

How can I assign single task to multipule assignees? I am struggling to find how I can do this.

37 answers

3 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

24 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 24, 2013

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

rawduk January 24, 2013

What is a search engine?

Like # people like this
rawduk January 24, 2013

Google? Whats that?

Like Ajay Singh likes this
Jozef Kotlár
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 24, 2013

Google maybe?

Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 2, 2013

Mathematical term for a 1 followed by 100 zeros

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 2, 2013

Googol != Google :-)

Like # people like this
Scott Beeson
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 27, 2015

THIS was the first hit on a famous search engine I use :)

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 27, 2015

2 years, it must have crept ahead of the official page!

Greg Dutko January 7, 2016

Now this page is actually the first hit.., LOL...

Like # people like this
2 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 11, 2016

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.

2 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 10, 2016

I think this has been answered to death.  Multiple assignees don't work in the real world because there's no clear responsibility.  It can be very useful to have secondary assignees as well, but in reality you always want a single owner.

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

93 votes
Henning Tegner August 25, 2016

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!

24 votes
Roberto Rocha Rodrigues June 1, 2016

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.

10 votes
Roberto Rocha Rodrigues June 2, 2016
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.

6 votes
Tatjana Domnina January 9, 2017

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? 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 9, 2017

>Maybe in some average situations.

If by "average" you mean "all real world cases", yes.  I've yet to find anywhere where "i thought someone else was looking at it" has not happened.

It's not a double standard, it's real-world deliberate design.

Like Flash_Sheridan likes this
Henning Tegner January 9, 2017

@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.

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 9, 2017

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".

 

Like # people like this
Henning Tegner January 9, 2017

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.

  1. I highly doubt that you've done an exhaustive survey of everyone in the industry
  2. I and many more people have seen that this can work. I won't go into how, because I've already written this up on the thread. Following your analogy, many have eaten foxgloves, and have survived, and even loved and have benefited from it. And it's not a miracle.

I think there are legitimate reasons for having this feature, but you just won't admit / see it.

Like # people like this
motherg January 9, 2017

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). 

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 9, 2017

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?

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 9, 2017

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.

Like Flash_Sheridan likes this
Tatjana Domnina January 9, 2017

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 smile

Image 09-01-2017 15-26.png

Like # people like this
motherg January 9, 2017

Nice one Tatjana, I hadn't seen that field before smile

 

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 9, 2017

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)

Like Flash_Sheridan likes this
mi_volodin January 12, 2017

@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 smile

 

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 12, 2017

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.

Like Flash_Sheridan likes this
Leonie Wolf February 16, 2017

@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.

Derek Toro April 24, 2017

@Nic Brough "No-one has yet come up with a scenario where multiple assignees cannot go wrong."  This is the equivelant of saying, "prove God doesn't exist."  You can't prove a negative. You are simply an obstinant person. 

Like # people like this
6 votes
Jobin Kuruvilla [Adaptavist]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 24, 2013

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.

rawduk January 24, 2013

Thank you for your help. It was the most useful and a quick fix. Unfortunatly the search is not great if its not pre personalised from a previous search. Which is why I couldnt find a suitable solution.

Like # people like this
3 votes
Henning Tegner August 25, 2016

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.

2 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 2, 2016

Yes - that's exactly how most people do it and it works fine.  You have one single assignee (primary) which changes over time, and then other people who are involved as secondaries.  It's not multiple assignees, it's single assignee with others.

2 votes
Melanie of Ottawa June 2, 2016

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.

 

 

2 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 2, 2016

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

2 votes
Jeremy Brooks June 2, 2016

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?" wink

1 vote
Martin Gray June 7, 2017

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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 7, 2017

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

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 7, 2017

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.

1 vote
motherg August 25, 2016

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.

1 vote
motherg August 25, 2016

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.

1 vote
motherg August 25, 2016

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.

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 22, 2016

You've still missed the point, sorry.  Could you re-read the last comment?  Where you should realise that while pairing is the one case where it's valid, it's also of no use, because you're paired, so it doesn't matter.

1 vote
motherg July 22, 2016

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.

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 20, 2016

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)

1 vote
Jason LeGris June 20, 2016

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.  

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 2, 2016

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.

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 2, 2016

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.

 

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 1, 2016

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.

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 1, 2016

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.

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 27, 2016

So, when you have two assignees, which one of them is ultimately responsible?

It does make sense to have many people who might need to work on it, in different roles, and people who are involved for various reasons.  But more than one assignee fails.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 25, 2016

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.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 25, 2016

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.

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question