How to indicate "Action Required By"

[Kevin Mote]

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?

[Renjith Pillai · Accepted solution]

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)

[Nic Brough -Adaptavist-]

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.