Handing over an issue from one Jira assignee to another is more than pushing ‘assign’, changing the assignee, and hoping for the best. A proper handover requires that the person who is receiving the Jira issue knows the requirements and is able to commit.
With the flexibility of Jira, you can configure many assignment approaches, such as:
- Throwing it over the wall
- The traffic agent model
- The ping pong game
- Passing the baton
What can go wrong when assigning issues in Jira to a new assignee
Everyone has their own agenda, and one thing we want to avoid is Lola assigning work in Jira to Kevin, without Kevin acknowledging the task…
Also, it is important that when Kevin ‘receives’ the Jira issue, he fully understands what is expected. Issue descriptions are not always capturing all the details. So Kevin should have an opportunity to discuss the request, determine a proper approach, and assume full responsibility.
Assigning tasks in Jira by throwing it over the wall
The first approach is when someone is assigning an issue in Jira to someone else. It is a bit like throwing a problem over the wall – imagine the following assignment, which says it all:
Hilde is not going to be very happy when she’s coming back from holiday and discovering she’s the assignee to this Jira issue.
The problem is urgent, the customer didn’t receive a timely answer, and you associate her name with the problem. Nice way to get started.
Grant authorization to a single traffic agent to appoint new Jira assignees
The traffic agent approach is the one where one user, mostly the team lead, has the authorization to hand over issues in Jira to new assignees.
She or he can then ensure that the tasks are clearly defined and commitments have been properly taken.
But, of course, this person is not always available. And creating a bottleneck in the process is never a good idea.
Assigning Jira issues by action: the ping pong game
You can either define the Jira assignee as the person who has the responsibility to resolve the issue or the person who needs to take the next action.
In the latter case, we call it the ping pong game, reflecting the situation where a Jira issue is being tossed around as a hot potato.
The advantage of this model – where the assignee is the person to take the new action – is that it is easy to list all the Jira issues someone has to deal with.
This approach is fine as long as it is clear how it can be escalated in case the issue doesn’t get resolved – who is carrying the responsibility?
Passing the baton in Jira, a polite handover method
Passing the baton is the only approach where you can appoint yourself as a Jira assignee, confirming that you want to take the responsibility of handling an issue.
If Lola wants Kevin to take over an issue in Jira, she mentions him in a comment. Kevin can assign the issue to himself (or send another comment):
This is fine, but doesn’t work well during scrum and planning meetings, where you want to have the liberty to assign to Jira at will.
Conclusion
As always, there is no silver bullet for this type of configuration. Every project and team has its own way of working in Jira.
In our case, we have a mixture of models – either ‘passing the baton’, or ‘the traffic agent’ depending on the situation at hand.
