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?
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 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.
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 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.
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.
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.
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
