Who is responsible for updating and moving Jira Tickets?

[Josh Kinney]

Let's assume developer1 grabs a story and moves it to "In Progress"

Developer then does the needed work, updates the story with appropriate comments, and finally moves the story to "Code Review" 

For this team code review is where another Developer (lets say developer2) looks over the Story and code. 

The code looks great with no issues... 


My question is; who is responsible for moving the story to the next step? Dev1 or Dev2? 

AND WHY.....

[Walter Buggenhout · Accepted solution]

Hi @Josh Kinney and welcome to the Community!

As you put it, developer 2 is responsible for code review. He/she supposedly ends that review with a conclusion to that review: ok or not ok. Seems to me that the person doing the review is the one who moves the ticket back to developer 1 (in case of problems), or indicates that the review is ok. Moving the issue to the next step is actually saying in Jira what the outcome of the review was.

Hope this helps!

[Josh Kinney]

This is exactly what I thought. Thank you for clarifying. 

[Joy R. Davidson]

There could be many answers to this question.

Scenario 1:
One Jira ticket exists for the task:

In this scenario, the developers are usually responsible for updating and moving their Jira tickets. As they complete tasks or encounter new information, they should update the ticket to keep everyone on the same page. Additionally, when a ticket needs to be moved from one status to another, such as from "In Progress" to "Code Review," the developer assigned to the ticket should make that change.

Scenario 2:
Two Jira tickets exist for the task:

If the task has been broken into two stories, for example, "Development" and "Code Review," then each developer assigned to the ticket should make the changes.

Scenario 3:
One Jira ticket exists for the task, and sub-tasks live on the ticket:

The developer assigned to the ticket would usually make the changes to the item, while others assigned to sub-tasks make changes to the sub-tasks.

While there is no one answer, here are a couple of options, and getting a team agreement is essential.

Cheers,
Joy

[Jim Glenn]

it's team preference. No solid rule. 

Some teams like to assign the tickets in review to the person doing the review (I have especially seen this in teams that have dedicated QA people). 

If the QA person (or Dev2 in your example) detects a problem, they comment, reassign back to original dev with notes and that makes it back to the original dev's todo list. 

Some teams would rather keep the ticket with the person doing all the work (or assign it back to the original dev when the ticket is completed) so that at the end of the sprint you have better stats of what dev did what in the sprint.  If all tickets ended in QA or senior dev to review, it looks like all the work is done by them. 

On the other hand, if you don't reassign to the person that is doing the review, you are asking that second dev (usually a senior dev) to keep track and on task with their own todo list and to keep track of what others need them to review. 

----

I've also seen teams use epics to define the requirements better and separate tasks (tickets) underneath that epic is done, tested, and closed (and kept assigned to 1 dev).  The testing of the entire feature (epic) is done by the owner of the epic, i.e. the project manager, QA, or a senior dev.  This allows full end to end testing of the feature based on a re-review of the original requirements while allowing an individual dev to focus on a specific part and be responsible for that part from beginning to end. 

So, in conclusion it really comes back to what your team agrees to do, how they use the reporting of the epic, and how they want to pass work between team members. (the technology doesn't enforce a strict policy)