We use JIRA's Scrum boards. As tickets are added into the Active Sprint, each ticket is assigned to a developer with a Status = "Open". The developer will then move it into "In Progress" to start work.

Once a ticket is ready to be reviewed by the Reporter (e.g. project manager, etc), the developer will change the Status to "Ready for Review", but keep the Assignee to himself/herself.

At this point it time, should the ticket Assignee change to reflect the person that has to act on it next?

  • 1
    As an aside, I've never found JIRA to be particularly agile. At heart, it's a ticketing system, and this sometimes forces certain workflows on its users. It's not a bad tool; I'm just pointing out that these sorts of questions arise when teams have to build processes around tools, rather than picking tools that support their existing processes. YMMV.
    – Todd A. Jacobs
    Commented Apr 3, 2016 at 21:56

3 Answers 3


A common practice is to have the assignee reflect the person who is working on the issue. This is done for several reasons:

  • It is easy to work out who is working on a ticket by checking the assignee field
  • It is easier to send out notifications (e.g. in JIRA a user recieves a notification when an issue is assigned to them in the default notification scheme).
  • The assignee can log time to the issue

It is worth noting that issues contain a history of who has worked on them. So, if in your situation the reporter wanted to assign the issue back to the developer they could check the history to find out who did the work.

Alternatively you could consider adding a custom field called something like 'developer name'. The developer would put there name in this field before assigning the ticket back to the reporter. Then it would be even simpler for the reporter to know who did the work.



Once a ticket is ready to be reviewed by the Reporter (e.g. project manager, etc), the developer will change the Status to "Ready for Review", but keep the Assignee to himself/herself...At this point it time, should the ticket Assignee change to reflect the person that has to act on it next?

There is no universally-correct answer to this question. However, in my experience there are two common workflows to consider: ticket-owner and task-performer. Which one will work best for you will depend on your organizational structure, team culture, and the project's communications plan.

"Ticket Owner" Workflow

This workflow is based on the idea that a ticket has an owner who is responsible for shepherding it through your process. JIRA is somewhat limited in its ability to reflect collective or collaborative ownership of tickets. While it's technically feasible (albeit inconvenient) to assign tickets to a group, none of my enterprise clients ever do this.

Instead, the ticket owner will often use the mention features in ticket comments to engage specific task performers. For example, if the ticket is assigned to Bob, he might change the status to "Ready for Review" and then add a comment to the ticket like the following:

[@alice] Please review feature foo by Friday, and let me know if solves the embiggening issue described in the ticket.

This will notify Alice that she has something to do, and she can likewise reply in the comments as well when the review is done, or when she needs help or clarification. This fosters communication and collaboration, despite the assignee field itself not being a particularly agile way to denote team (rather than individual) ownership.

"Task Performer" Workflows

Task performer workflows are composed of either hand-offs or subtasks. These are less agile workflows, in my opinion, but they can work well when the goal is to monitor or track who is doing what, rather than focusing on collaboration. The main downside to both of these approaches is the reliance on push queues rather than pull queues, which makes it harder to manage work-in-progress limits or accurately estimate workloads in advance.

Assginee Hand-Offs

In this workflow, work is handed off to other people by explicitly assigning them to the ticket. For example, once Bob has embiggened the widget, he can then assign the ticket to Alice to for review. When Alice is done with her review, she can assign the task back to Bob, or to whoever is responsible for the next step in the ticket.

Subtask Assignments

Instead of changing the person assigned to a ticket, a task or story owner may create subtasks and assign them to specific task performers. However, this workflow is less flexible than either mentions or assignee hand-offs because you can't create subtasks of subtasks in JIRA, and the additional task management creates additional process overhead that can quickly swamp small or fast-moving tasks. Also, the very act of assigning subtasks to people rather than collaborating with them is a project smell that whiffs of command-and-control rather than agility.

On the other hand, the subtask workflow has a few benefits within JIRA. Individual steps become trackable as first-class items on the Kanban board, and it can help decompose larger tickets into items which are either done or not-done in a more visible way.

  • 1
    In my experience, using the "mention" feature to require someone to do work has the same weaknesses as using email to assign work: Unless the work can be done at once, it requires each user to invent their own system for tracking their to-do tasks. There is nowhere in JIRA where you can get a list of "incomplete mentions". Normally the result is that people will be managing their todo-list in their email client in more or less effective ways.
    – Mikkel
    Commented Apr 8, 2016 at 16:00

I had the same problem, What I did is add a custom field, "Ball In court". as I needed to keep the assignee for the issue stuck to the developer for reporting purposes .

If you do not want to add custom field, It is best to create a state in your workflow, "Needs review by PM" and allow the dev to move move from in progress to this state.

Now create a simple board for pm and add this state issue to a column,

I can elaborate more if you provide multiple scenarios, the issue can go to from one state to another

  • It never occurred to me that I could have more than one board for a project, and customize them for their audience! Thank you, I think this will be extremely helpful as I move my projects to JIRA Commented Jun 3, 2018 at 0:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.