Assigning Jira Issues

[Dave Menconi]

Traditionally bug tracking systems were used for software. Initially they tracked bugs (hence the name) but were also used to track features and releases. Many of us learned everything we know about computers by living the cycle of writing, testing, fixing, and releasing software, a process controlled by bug trackers.

In traditional software development, every buy or feature is assigned to one and only one developer. It was kind of convenient because I always knew what to do next: just work the tickets assigned to me in priority order. I always assumed that an unassigned ticket was a ticket that would not be worked on by anyone. Essentially, a “lost” ticket.

So when Jira luminary Rodney Nissen (“The Jira Guy”) lamented on The Jira Life Podcast that the Assignee field could only have one user I was baffled. I agreed with podcast co-host Alex Ortiz that allowing only a single assignee is a good thing.

I’ve seen teams who didn’t want any form of auto-assignment on their tickets but they never explained to me (a lowly Jira admin) why. Perhaps you have experience with keeping tickets unassigned and maybe it works great for you. Could you share your experience on this topic?

[Nic Brough -Adaptavist-]

Much as I dislike disagreeing with people, especially community leaders such as Rodney, he is wrong.

The assignee of an issue is the person currently responsible for dealing with the issue. 

That does not necessarily mean they are the person working on it, nor the only person on it.  It does not mean they "own" it, or that they are the only person who might have to take responsibility for getting it done.

In real life, you will find that multiple assignees, groups assigned, teams assigned, etc causes project failure or over-run because as soon as you put a human in the position of being able to say "I thought someone else was dealing with it", it will happen.  I have never seen multiple assignees succeed in any place, it has always failed.

Of course, there is absolutely nothing wrong with having additional data - having a group or team field as well (you might even say "assignee must be in the selected team/group"), but the assignee is there to say "this is the single person ultimately responsible".

At a small scale though, leaving it blank and using a team representation can work.  But only when the team is small and works closely together - a Scrum team is a good example.  It doesn't matter if an issue is not assigned to a team member, the whole team are talking every day about what is on their boards, and the scrum master or product owner is able to talk to other people and teams about the issue rather than have someone bother the assignee.

There are lots of approaches to team assignee, but the ones that I have seen work best with "unassigned" are:

• Jira's Scrum and Kanban boards are designed with a premise of Team = Board.  A team works off a single board, so if the issue is on their board, it belongs to their team.  (Boards include the backlog, of course)
• JSM's Service Desk projects can be thought of as using "Team = Queue".  People tend to have many queues for different things, but I've seen it be very effective to have a "team queue", where the team knows it should always be taking the top issue off the queue next (an assignee can help if there's a lot of agents, or they're not talking frequently)
• In Jira Work Management, unassigned does not work.   You need an individual to take responsibility for the issue; there's no way to represent responsibility. 

[Randy O_Neal]

@Nic Brough -Adaptavist- you are 100% right.  This - for me - has always boiled down to Project Management 101 and the concept of One Throat to Choke - who is responsible for the issue?  This does not mean that person is the only person to work on it, and it does not mean the issue belongs to them solely; they will be the person asked for updates or any concerns regarding the issue, and if anything is needed, there is an expectation the assignee will reach out for assistance.  As you indicated, assigning an issue to multiple people simply does not work... I've been managing projects for >20 years, and I have more examples of how this failed than I could ever begin to count.

My teams spent nearly 10 years as Scrum teams; we've recently switched to Kanban.  We have always operated under your first bullet premise that Team = Board.  By working off a single board, the full contents of the board belongs to the team.  Things get "fuzzy" when we have issues on the team board which are actually being worked by people who are "dotted line" members of our team, such as our Platform engineers (who - in reality, are "dotted line" team members of all our organization's teams).  We do this on occasion so that our team has direct and clear visibility to the work the Platform guys are doing to directly support our team, but such issues are rare, and usually demand extra transparency and visibility.

We leave our work largely unassigned until it is ready to be pulled from To Do to In Progress; we do not allow In Progress work to remain unassigned.  In some cases, we know well in advance who will be the assignee due to special knowledge or special skills, but by-and-large, we leave issues unassigned until we decide to pull them into progress.

BTW, you can draw a lot of parallels between your second bullet point about "Team = Queue" to how Kanban teams operate.  I could write more, but I won't belabor the point.

[Rick Westbrock]

In the same vein a service desk agent may be assigned an incident to ensure proper communications to the customer even though the actual resolution of the issue is being handled by an engineer in a linked Jira Software issue.

In my engineering team we have a rule to leave issues in the backlog unassigned so that when someone has spare cycles they can just grab any unassigned issue. Similar to Randy any issues that have exited the backlog must be assigned to someone.

We also use "group assignments" in part due to how we are currently using Remedy for ticketing (where there are separate fields for Assigned Group and Assigned User). To accomplish this in Jira we have what we call "virtual user" accounts which use the distribution list e-mail of a group; when an issue is assigned to the virtual user it is "owned" by the team and from there an individual assigns it to themself to work on it. My team specifically uses this for our incoming work project where end users submit issues.