My point is about logging time. Often is does occur that more than one user is working on a task. If in the sprint meeting it is said it takes a week, do one task - do the sub-task time entries than combine to get the real picture as in how much time is spent against the planned time for the whole task ?
This is a constant problem for many in Jira, we need the ability to notify or assign more than one person to a task on occasion. Why does Jira keep giving responses to defend their position? I thought their role as developers was to listen to users and respond accordingly with new features?
This is not a problem of Jira, but a problem of processes having more than one RESPONSIBLE person for a task at a time. Think about your processes, split a task to subtasks & you got the solution. And no, I’m not Jira, I‘m a customer. Mapping traditional processes to Jira often uncover the faults they have. Jira is a tool, which doesn’t make bad processes better...
Interesting that a software designed to facilitate working in teams does not allow this. Also the guy who is so stubborn he keeps commenting 'you can only have one person responsible' clearly has his head up his ass and does not understand that there is already a 'Reporter' field that is the person responsible for the completion of the task (the one you report to). Not the ones you assign it to. That's basic management hierarchy. So why can't you assign something to more than one person? Utter BS that promotes individualism, not teamwork.
There is a workaround to do it!
This is CONTROVERSIAL topic. It seems like JIRA stance is 1 user - 1 story, and it makes sense to have single point of responsibility, but real life more complex than that.
While there is no way to do it directly with Assignee field, you can do the following:
1. Create Multi User Selector custom field
2. Show it on the screen
3. Hide Assignee field
If you like me is more of a visual person, I have created a small Youtube video how to do it here
As @Gikku said its right, but you can make custom field as multi user picker and then assign it to the screen of your project and when you want to assign a task to 2 or more users, you mention all users in that. And for sending notification you can add the custom field that you have made.
I can recommend to try the ActivityTimeline add-on to solve the issue with multiple assignees. In some cases creation a sub-tasks are not a solution. As an example, when you need to split task between different days for the same user.
Also there are possibility to manage how many hours are going to be put in each part of the ticket and give an additional flexibility for resource planning.
How to set up a multiple assignee is in our blog.
Understood. However why can’t you have one owner and then people that are secondary/supporters. You don’t always want to break down a task into too many sub tasks.
User Stories need multiple roles like Product Owner, Business Analyst, UI, Tech etc. to work on it at the same time.
Am I the only one that thinks that multiple task per role / resource are overkill and add additional complexity for users as well?
You could see the "Assignee" of an issue as the person being responsible for it. What you can do, is creating a multi user custom field with the persons working on the issue. Still, one person is responsible (assignee). If you have many workers on an issue, who defines that the issue is done/finished?
Hi, Why we need multiple assignees for single stories because we have columns for Ready for QA. Whenever we estimate any task we estimate with testing time. So I want to assign tester in every user stories otherwise its difficult to manage multiple tasks for one particular feature.
It's actually not difficult: Auto create a subtask for each tester, where he has to estimated his testing time. This allows also for easy checking which tester didn't submit his estimated. You can then sum up the estimated time on the single story.
Simply read the assignee of an issue as responsible contact for progressing the issue & the person to contact, if there are questions on the process of the issue.
I have the sentiment that every team has their own use cases - so they have processes that are unique to them. Sub-Tasks are not that convenient or worthwhile workaround for us. Extra ticket management and they don't report the same as story's.
With everyone starting to use pair programming, mob programming, team or partial team swarming techniques that teams like to use and currently Jira does not make it easy to view multiple people who are working on one ticket to solve and complete that ticket.
I agree with ownership or responsibility could be the first person listed. To Improve visibility on the board it would be nice to see multiple people (assigned) and working on the ticket. This is a feature Jira should provide since many teams are evolving the way they work.
Maybe Jira can't easily provide so they use 'process' and 1-ticket -- 1-Owner excuse??
This is somehow of a pain for me as we have a frontend developer and backend developer working in the same time and both are responsible. Assigning muliple people would be much more useful as they will also get the notifications regarding changes in the ticket.
Sub-tasks do not solve the issue as it is double the work for me as PO. Maybe I would try to simple sub-tasks: create BE and create FE....but still would really love to assign multiple people.
You should try to automate the creation of subtasks, based on criteria you define in your issues. The assignee is the person responsible to move the issue to the next state. Who is doing this if more than one person is assigned? If there are two persons assigned they have to communicate with each other on either the work of the other one is complete or not.
I would always try to split up work until it can be assigned to a single person.
Just my 2c...
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