How to indicate "Action Required By"

Imagine a situation where a ticket has been assigned, but the assignee is waiting for information (or whatever) from someone else on the team.

  1. Should the Assignee reassign the Issue (along with a comment like, "I need J's input on this before I can continue")?
  2. Should I (the system admin) reconfigure JIRA with a new role called "Action Required By", so the Assignee could put J's name in there (but still retain the ticket Assignment) as a way to indicate that he's waiting on J? Then a manager could look at a stalled ticket and easily see why it is being held up.

If a ticket is being blocked by a non-responsive team member, there ought to be a way to indicate that in one of the fields.

How do you normally handle this situation?

1 answer

1 accepted

0 votes
Accepted answer

It really depends on your usecase and also the culture/process in your team. Different ways:

  1. If you really need a very clear process (which might be an overhead) is to have a workflow status called (escalated) or waiting for inputs which also changes the assignee to the second person. This will help you later to derive statistics on which status the issue was lying for more time. But think about a case when a third person is needed now to give inputs. It is not now pratical to add another level. It becomes too much of an overhead.
  2. Add a custom field to indicate who has to give inputs and also add notification using that custom field so that the second person comes to know about it.
  3. Just change the assignee to the person with a comment what is expected from the second person. This is the cleanest and the easiest option and everyone just keeps working on issues assigned to them. Also JIRA administration remains simple (my preference)

Option 1 tends to work best in my experience, although it is a bit of a faff for the admins as Renjith said. It makes it absolutely clear that the issue is blocked by waiting for input from a specific person and reporting on "issue can't be done becuase..." becomes really simple. Option 2 can be done with it of course, which helps with the involvement of many people, and there is absolutely no reason not to let other people contribute before they're needed as well.

It does depend on exactly how your organisation works though. Option 3 can be better for small teams and/or teams who work closely together because they will tend to talk to each other well. Option 1 is better for situations when the dependencies are outside the team using the project (e.g. we're writing a thingy, but we need input from corporate people about the UI). If you're using Jira to handle support work, option 1 is pretty much mandatory - you need at least one "waiting for feedback from user" type status.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,711 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you