Let's say our workflow is like this: DEVELOPMENT, CODE_REVIEW, TESTING, DONE. Developers get assigned to work items and start working on them.

When an item is implemented it needs to be reviewed by another developer from the team - should we change the Assignee field from the developer who was implementing it to the developer that will be reviewing it?

And the same question when an work item needs to go from CODE_REVIEW to TESTING - should we assign it to a tester?

If we don't change the Assignee field filed then the item becomes kind of un-owned when it transitions from DEVELOPMENT to CODE_REVIEW (or from CODE_REVIEW to TESTING) - nobody will consider themself responsible for this item (especially when they have their own unfinished work items).

But if we change the Assignee field then we lose the information about the original developer - it doesn't seem to be convenient.

2 Answers 2


There are lots of different approaches you can use for this.

For example, I worked with one team that used custom fields to show the individuals that were involved in a ticket (e.g. "Developer", "Tester"). They populated the custom fields using pop-ups during transitions. This saves people from having to trawl through the ticket history, but it can get a bit confusing if a ticket is re-opened.

Another team I worked with would use a default assignee for each stage of the process. The default assignee would take responsibility for the ticket until they either did the work themselves or handed it off to somebody else.

My advice would be to try an approach for a few weeks and see if it is working well. Focus on the value you are trying to get from the visibility of assignees.


Jira items have a history. When you move items from one column to another, that change is recorded and you have the history. You can find out who all the assignees were.

And to be honest, that goes for your people too. If you move one item from "development" to "code review" and you re-assign the Jira issue, you still know who developed the code, don't you? That person doesn't develop amnesia once the issue was just developed. People still need to communicate with each other on issues and they need to know about each other for the development, review and testing to go well, with the issue assigned or not. That goes even for people who are remote. They can't just receive work on one side and pass it on once they are done with it. You need collaboration.

If you think people are more responsible with their work if it's assigned to them, then assign the issues as they move through the workflow. Jira will give you the history, maybe even notification emails, etc.

  • Thank you! Yes, I know that Jira issues have a history. It just seems to be a little inconvenient to change the original developer. I have never done agile project this way. Commented Jan 1, 2020 at 17:52
  • 2
    One of the Agile values (Kanban included) is "Individuals and interactions over processes and tools". So don't focus so much on getting things done perfectly from the beginning, you can even try it both ways. If you see some gain in changing the assignee, do it. If you don't, then don't. And just to mention the obvious, responsible people will be responsible with their work even if it's assigned/re-assigned in Jira or not while irresponsible people will still be irresponsible with their work even if it's assigned/re-assigned in Jira or not.
    – Bogdan
    Commented Jan 1, 2020 at 18:11

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.