We currently have Reporter and Assignee fields for Jira stories. For example, let's say we move from the 'Code review' column to the 'Ready for testing' column. Should the tester then come in, delete the original coder's name from the story, and put his name as the assignee? I'm used to Azure Devops where if a tester comes in, I believe there are fields for multiple assignees (Assignee field and QA Tester field).

But I had this tester remove my name, so in my standup, it suddenly looked like I had no work on the board (nor any work completed), and I had trouble finding where the heck my story went. It seems incorrect to delete the original coder's name and then put the tester's name just for some smoke testing tracking (at the expense of engineering tracking)- but maybe I'm incorrect? What's the way to go around this in Jira where there's just one Assignee field?

  • 2
    I was writing up an answer to this question, but everything in the answer dealt with communication and people problems, and how to use a tool. All of these are off topic for this site. We deal with conceptual problems about software engineering. This is not conceptual. Consider posting this on The Workplace instead. Mar 25, 2022 at 19:31
  • Since this concerns Jira best practices, pm.stackexchange.com might be a better fit than Software Engineering or the Workplace.
    – Llewellyn
    Mar 26, 2022 at 22:18

1 Answer 1


This depends on your workflow.

Some teams that I've worked with do change the assignee from the developer to the tester when the work enters test. The fact that it doesn't look like a person has or did any work isn't a problem - these teams tend to view the work as the team's work. Plus, if someone did need to know who the developer was, you can write JQL queries using the assignee WAS option to find issues that were ever assigned to a particular user or just browse through the history tab of a specific issue.

However, other teams did like to retain information about the developer. In these cases, you can use custom fields. You can add custom fields to issues to capture information like testers or even other developers (since Jira limits issues to one assignee) who may have been involved in pairing or perhaps UX designers who were involved in creating/updating mockups. Custom fields in Jira are quite powerful and you can include them in JQL queries for filters, user dashboards, or boards to better visualize the state of work.

Both of these are valid solutions. The tools should support the process, so the team should understand what they want to achieve and how to best configure the tool to support their way of working.

  • Thanks for this. I really see all 'cons' and no upside with the first preference (only one field). It's demotivating and confusing for your engineers - you never have anything in the 'done' column. This also can make it hard for your team and management to evaluate your workload. It also makes it extremely taxing to find who coded what from a board level - you have to guess which story, click into its view, scroll down and click history, then scroll through and hope to find the event where tester changed assignee. All to track smoke tester's progress which is typically 5 - 30 min of work max. Mar 25, 2022 at 19:51
  • 1
    @KyleVassella These cons seem more like organization issues rather than cons. It seems to be centered on individual performance over team performance. Getting work done or evaluating workload should be on the team level. Changes can be better viewed in source control rather than issue tracker.
    – Thomas Owens
    Mar 25, 2022 at 22:36
  • But if we use bitbucket, our issues are pulled in via Jira. Removing the original assignee undoes all of the tracking statistics for that user. I can't click the backlog button and filter by my stories anymore to see what I've worked on in the past. Bitbucket by default doesn't have contribution charts like Github, so I can't use that to see my past work. I have to rely on Bitbuckets 'my recent pull requests' section which doesn't go back that far and is a mixture of every action I've ever taken, rather than stories. Below that, stories section pulls from Jira aka useless once assignee changed Mar 25, 2022 at 23:23
  • All of these cons, again to improve tracking for the tester, at the expense of the engineer. What would the con be for just including a 'QA Tester' custom field? I see none at all. But without a second field and just deleting the original assignee - again, I see many cons. It makes your work history as a team and as an individual a complete mess to sort through. Mar 25, 2022 at 23:26
  • 1
    @KyleVassella It's not just about testers, though. What if you get sick or go on vacation but the task is urgent, so a colleague takes over the task? Would you still argue it's demotivating to see the task assigned to someone else when you come back? What if you're pair programming with a colleague?
    – Llewellyn
    Mar 26, 2022 at 22:23

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