Automatic task assignment in Jira

A common problem for a project manager is to determine on whom the further execution of the task depends. Often the task is assigned to the developer, and so it remains to “hang” on it until the release. However, the developer is only responsible for part of the execution. QA - tests, DevOps - includes the release, product manager - evaluates the finished work (in each organization, this chain has its own). The task travels from status to status (In Progress, Done, Tested, Shipped, Closed, etc.), but the developer is still the developer.

In small teams it is not difficult, after all, it’s pretty clear that who should test, who should release, etc. But even a team of several QAs already need to reinvent the rules by which testers must parse their tasks, marked by developers as Done. Or a special person must manually distribute such tasks among team members. And the most annoying thing is that there is no guarantee that the task will not be forgotten and will not get stuck in any intermediate statuses.

The proposed solution is the automatic installation of the executor of the task when it enters a new status. For example, as soon as a developer marks a task as Done, she will automatically be assigned to a QA engineer.
')
The advantages of this solution:

• personalization of responsibility for the task at every stage of her life
• the new executor will receive a notification from the system about the task assigned to him
• more accurate reporting - for example, you can create lists of tasks currently owned by each team member
• increased readability of tasks in all Jira interfaces (detailed view of the task, Agile boards, etc.)

Jira contains the necessary functionality in its bins. Let's take a look at how all this utility is configured.

As a simple example, suppose that the team includes a Johnny Testcase QA engineer, to which all tasks assigned by developers to the Done status should be automatically assigned.



Jira allows you to customize additional actions performed when a task transitions from one status to another. The whole system of statuses and transitions is called workflow, transitions are transitions, and additional actions during transitions are post-functions. Our task is to add post functions to transitions that will install a new artist.

Before editing a workflow used on a live project, it is recommended to copy it and train it on a copy.

So, open the editing screen of our workflow:







In the transition scheme, we are interested in the transition from the In Progress status to the Done status. Open the edit screen for this transition:



On the Post Functions tab, select the Add post function:



From the long list of possible post-functions, select the Update Issue Field:



Thus, we will configure automatic update of the value in the specified task field. Select the Assignee field (performer), and specify our imaginary QA-engineer Johnny Testcase as a new performer:



Note that a new post function has been added to the list:



The workflow setup is complete, it remains to publish it:



The changes will take effect for all projects that use this workflow. All tasks transferred to the Done status will automatically be assigned to the above Johnny Testcase.

In practice, such a straightforward scheme is unlikely to be very applicable. However, a rich set of available post-functions allows you to set up very useful rules. Here are some of the post-functions that are most suitable for combat use:



The author in practice uses the following simple scheme:

Transition	Who is the task assigned to	How implemented
In Progress → Done	On the lead of the QA team. He manually redistributes the task to one of his team members.	Post function Assign to role member . At the same time, the project defines the role of the QA team lead, which is indicated in the post-function.
Done → To Do	On the developer who worked on the task before.	This is the case when the test failed, and the tester reopens the task, i.e. returns it to the developer. Implemented using the post-function Assign to last role member . In this case, the project defines the role of Developers, which includes all the developers.
Done → Released	On the person who created the task (Reporter).	It is assumed that the product manager evaluates an already completed task. Implemented using the post-function Assign to reporter .

Readers are invited to share experiences and suggestions on the possible organization of schemes for the automatic transfer of tasks between performers.