nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Are there best practice recommendations on whether the assignee field should be Unassigned after an issue is Resolved?

Madelyn Meek

I'm finding there are arguments for and against on this, there are a couple of line managers who want to view issue reporting for their direct reports that sit in the agile teams, if we take the assignee off after an issue is resolved it messes up their reports. However there is an argument that it doesn't make sense to leave someone assigned without there being anything to do. I'm wondering if there are some guidelines or best practices that might help firm up a decision?

Accepted answers

Rahul Aich [Nagra]

I strongly believe that assignee field should never be left unassigned. If a newissue is created and you are not sure whom to assign then it should default to either component lead or project lead.

Someone has to make a decision who is going to work on it.

Once the issue is resolved, it is important to retain the assignee field with the individual who worked on it. There are lot of reports which run based on the assignee field. It is also important for traceability purposes, to identify which developers are more productive than the others.

I agree, once a issue is resolved there is nothing more to do on it, but leaving the assignee in there is going to do no harm. You can still find out team's backlog of unresolved issues by updating your JQL query to filter only unresolved issues.

This is just my opinion. I leave it to you to decide what isbest for your organisation.

Rahul

All comments

Rahul Aich [Nagra]

I strongly believe that assignee field should never be left unassigned. If a newissue is created and you are not sure whom to assign then it should default to either component lead or project lead.

Someone has to make a decision who is going to work on it.

This is just my opinion. I leave it to you to decide what isbest for your organisation.

Rahul

Nic Brough -Adaptavist-

The "best practice" in this case is a bit vague, but boils down to "do what is best for your reporting"

Generally, they should be left assigned though. Your reporting on issues should be clear about whether an issue is currently open or not, and JIRA is built very much to ignore "ended" issues anyway. If you look at things like the "assigned to me" gadget, it explicitly ignores resolved issues. That means your users for the most part, don't care about resolved issues even if they're the assignee.

In your case, I'd leave the assignee on as your reports need it. Your assignees need to be trained to not worry about it - they should understand that a resolved issue can be ignored.

Madelyn Meek

Thanks very much, I think this highlights perhaps where we are managing issues in the wrong way. Issues typically go through quite a lot of people within the development team, whether its a coder, config person or tester. So ultimately all issues for us will finish their life with the tester who is the final person to handle it before it gets resolved...more to think about

Madelyn Meek

Thanks very much for the fast response!

Nic Brough -Adaptavist-

It may be worth a look at the workflow, or at least the end of it. Some of us set the assignee back to the reporter for final verification before close, but leaving the last assigned tester can be more useful too.

Phill Fox

As always JIRA is configurable to meet your business requirements.

I can certainly see the case of managers wanting reports but the question is what does the report actually show? Who has next action on an issue - in which case as you say having a complete issue makes little sense. If the report is about who resolved the issue then this may also be false as anyone could be assigned a ticket after the resolution has been set.

Many organisations use a 360° process where whoever reported the issue is responsible for confirming closure. What impact would this have on your reports?

I would recommend that you understand and agree with your managers what they use the report for and whether the underpinning data in JIRA actually supports such a report.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

jira-core