Multiple assignees in Jira: How to assign one issue to multiple people
Let's say you have one Jira issue, but several people need to work on it.
Maybe two developers are pair programming. Maybe a designer, developer, and QA engineer are all contributing to the same task. Whatever the setup, the question is the same: can Jira assign task to multiple users?
By default, Jira gives each issue one assignee. The assignee field is designed to establish a clear owner (no more than one assignee) — the person primarily responsible for moving the work forward. While Jira doesn't natively support multiple assignees for the same issue, there are several ways to handle it.
The right option depends on whether you need to split the work, record additional contributors, or plan how the work is distributed across multiple team members.
1. Create subtasks for separate pieces of work
If the task can be divided into distinct pieces, creating sub tasks is usually the simplest solution.
For example, you could create:
-
a development subtask for one developer;
-
a design subtask for another team member;
-
a QA subtask for the tester.
Each person gets their own assignment while the work remains connected to the same parent Jira issue.
This approach works well when responsibilities are clearly divided, and project managers need to track progress on individual parts of a larger task.
You can create sub tasks directly from the parent issue and assign each one to a different person. This makes it easier to manage ownership, estimated time, and progress without changing how Jira's standard assignment process works.
However, creating subtasks doesn't always make sense. If two people are genuinely working on the same thing—for example, during pair programming—splitting the work into artificial subtasks can create unnecessary complexity or duplicate tasks.
In that case, forcing one task into several smaller ones may make the project management process harder rather than easier.
2. Assign multiple people with Planyway
Sometimes you don't want to split a task at all. You simply need to reflect the fact that more than one person is working on it.
This is where Planyway's Multi-assign feature can help.
- Multi-assign / Split can split a single work item between multiple users.
- The work item is then shared visually between them.
- Each assigned piece can have its own estimate.
- Each piece participates separately in workload calculations.
For example, imagine a task with 20 hours of estimated work. One person might be responsible for 12 hours, while another takes the remaining eight. This makes it possible to keep one Jira issue as the source of truth while reflecting how the work is actually distributed across the team.
This can be particularly useful when:
- multiple people contribute to the same issue;
- different people are responsible for different portions of the work;
- contributors have different workload allocations;
- team members join the work at different stages;
- you want to see how shared work affects individual capacity.
Because Planyway combines this with resource planning and workload management, each person's allocation can be considered alongside their other scheduled work. This gives project managers a clearer picture of who is working on what and whether the workload is realistically distributed.
3. Use a custom field for additional assignees
If you only need to show who else is involved, a custom field may be enough.
A Jira administrator can create custom fields such as:
-
Additional Assignees;
-
Collaborators;
-
Secondary Assignee;
-
Co-assignees.
Using a multi-user picker or user picker, you can add multiple people to the field while keeping one person as the primary assignee.
This option makes sense when the goal is visibility rather than workload management. One person remains responsible for the issue, while the custom field records other people involved in the process.
In Jira settings, administrators can configure these fields differently depending on the project setup. This may work particularly well in company-managed projects where teams need to apply the same feature or reporting structure across multiple Jira projects.
However, a custom field doesn't truly support multiple assignees in the same way a dedicated multi-assignment feature would. Additional assignees may not receive the same notifications or appear in standard Jira reports and workload calculations.
In other words, a custom field helps document who is involved, rather than manage how the work is distributed.
4. Use labels or components for team-level involvement
Labels and components are another option when you're trying to show which teams, departments, or functional areas are involved.
For example, an issue might be associated with both backend and design components.
This can be useful when work crosses multiple teams in Jira projects. You can also use other criteria, such as a group, department, or area of responsibility, to categorize the issue.
However, this doesn't assign the task to specific people. It provides context about team involvement rather than individual ownership.
If you need to know exactly which person is responsible or which developers are contributing, labels and components are usually too broad on their own.
Which option should you use?
Here's the simplest way to decide:
-
Use subtasks when the work consists of separate deliverables that can be assigned individually.
-
Use Planyway Multi-assign or Split when multiple people contribute to the same task, and you need to plan their individual workload.
-
Use a custom field when you want to record additional assignees or collaborators.
-
Use labels or components when you only need to indicate team-level involvement.
The important distinction is between ownership and contribution.
A Jira issue can still have one primary assignee responsible for the outcome, while several team members contribute to completing the work. You don't necessarily need to force every collaborative task into a structure that doesn't reflect how the team actually works.
Whether you assign multiple people, create subtasks, or split task allocations depends on what you are actually trying to manage: responsibilities, visibility, workload, or progress.
The right approach is simply the one that gives project managers and team members enough visibility without making the project unnecessarily complex.
Was this helpful?
Thanks!
Mary from Planyway
8 comments