Is it possible to assign a story/issue to multiple users?

[Angelos]

As far as I am aware the concept is that every issue is actioned by one person.

However you could achieve something similar by introducing a User Picker (multiple users) custom field in your issues (assuming you have JIRA admin rights).

You can name it something like contributors, and you can then define in your assignable permissions that only the people listed under this custom field can become assignees.

Personally I am not a big fun of multiple users working on a single issue as I like having clear ownership of tasks and surely each user will be doing something different. So I try to keep the actions between Reporter and Assignee.

Hope that kind of helps you and will be interested to see what others have to say.

[Ryan Flores]

Please see my comment that I made Nic Brough's response. I think this question has some merit to it.

[Nic Brough -Adaptavist-]

No.  Because there should always be one single person responsible for an issue.

But see https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users for some "workarounds".  I strongly recommend sticking to having assignee as the person ultimately responsible though (avoid the dummy user solution there) because I've never seen it work anywhere.

[Ryan Flores]

In scrum, a story can be worked on by multiple users, not just one person. Sub-task would then be worked on by individuals. For example, a *single* story can be broken down into a design task, front-end task, back-end task, database task, etc. Once the story reaches QA, then it would make sense for the story to be assigned to the person testing the story and validating that all acceptance criteria have been met. If a story can be put into progress without first having to assign the issue to an individual, then there might be no need for assigning a story to multiple users. The point of that would be making it transparent that a story is actively being worked on. Another concern would be the person who resolves the issue. If multiple people are working on sub-tasks for a story, they're all responsible for that story. However, JIRA only allows a single person to resolve the story. So who takes credit? This could potentially impact reports. I'm sure most people wouldn't want to generate reports at the sub-task level, but instead at the story-level. Thus, there is some merit to the question being asked.

[Nic Brough -Adaptavist-]

There is a lot of merit to the question, it's a very good one, and your different approach of having an issue remaining unassigned works really well when you can get a team to work with the clear understanding that "unassigned" means "belongs to all of us" or "it's not being worked on, and it's our responsibility to assign it and clear the assignee when appropriate". As you say, in Scrum, a story can be worked on by many people, and the best approach is to break it up into sub-tasks for individual assignees, and it's often common to leave the story assignee as completely blank. And I hadn't thought about the problem of reporting on "who resolved a story". I'm not sure how I'd handle that, although the main team I work with on dev stuff have their scrum master resolve stories after checking sub-task completion, so everything would appear to go through her, despite her not actually doing much code at all. For us, it doesn't matter that she's the person closing it, but I can see how that could be important in places. But that doesn't really get away from "multiple assignees for issues doesn't work" - I can't see any way to solve the "Tweedledum and Tweedledee" point that they can point at each other and say "he was doing it"

[Angelos]

The way we I do it is by utilising issue links. Basically the Project Manager / Scrum Master is responsible for the management of Epics & Stories and then Developers & other parts of the business are creating their tasks which they link to the stories with a custom Link called "Implements". This process has double purpose: 1. Empower the teams to manage their tasks as they like and write them up appropriately 2. In many cases one Development Task may implement multiple Stories in which case the sub-tasks won't ever work. The downside is out of the box reporting difficulties - but with a bit of JQL and possibly some excel exports different levels of the business can still extract the information they need.