In Agile, who's the person responsible of moving tickets in Jira (e.g. moving backlog items into Sprint). Is this a Scrum Master's responsibility or Product Owner?

New contributor
Mike is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • Are you asking "at the start of the sprint" or "in the middle of an ongoing sprint"? – Erik Dec 5 at 10:53
  • We're in the middle of the sprint. Thanks. – Mike Dec 5 at 16:19

According to the Scrum Guide, the Sprint Planning event is when the Sprint Backlog and Sprint Goal are created and the entire Scrum Team (the Product Owner, Development Team, and Scrum Master) collaborate to produce the plan for the Sprint.

Going into the Sprint Planning, the Product Owner should have an ordered Product Backlog. The items at the top of the Product Backlog should have been refined (through the act of Product Backlog Refinement) by the Product Owner and Development Team to ensure the Product Backlog Items have sufficient information to be worked on and the required effort is understood.

At the Sprint Planning, the Development Team can review its capacity and determine what work is appropriate to be brought into the Sprint, in collaboration with the Product Owner. The event can be facilitated by the team's Scrum Master.

During the course of the Sprint, the Sprint Backlog is entirely owned and managed by the Development Team. If the Development Team realizes that they will be unable to accomplish Product Backlog Items within the Sprint timebox, they should work with the Product Owner to ensure that the highest value work is delivered, and the Sprint Goal can be used to help focus the team. If the Development Team works through the Sprint Backlog before the end of the Sprint timebox, they can likewise work with the Product Owner to determine how best to use the time - perhaps bringing in some work earlier, spending additional time refining the Product Backlog, paying down technical debt would be good options to consider. The Scrum Master can help facilitate the discussions between the Development Team and the Product Owner as needed.


If you're looking to know who is using the tool, it could be anyone, including a member of the Development Team, who updates the work items in Jira to reflect the fact that they are included in the Sprint. It depends on the flow of the event and who is most comfortable using the tools while still fully participating in the event.

I would propose that in a new team that is learning the process and tools, the Scrum Master would be most likely to perform the work of ensuring Jira is up-to-date. The Scrum Master is responsible for helping to facilitate the various Scrum events and ceremonies. However, the Scrum Master is also responsible for teaching and coaching the rest of the team in the various ways of working. Ultimately, the Scrum Team should decide the best way to handle it.

TL;DR

Anyone with sufficient permissions in JIRA can move the stories during Sprint Planning. It doesn't really matter who actually moves the stories. What matters is that the stories are pulled by the Development Team, and never pushed.

Responsibility for Moving Backlog Items

The Scrum Guide clearly states that the Development Team is responsible for peeling items off the Product Backlog during the Sprint Planning event. The guide says:

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

In other words, the Product Owner is responsible for the Product Backlog, but the Development Team is responsible for moving those items onto the Sprint Backlog. The fact that you're using JIRA for both doesn't really matter here, except as an implementation detail.

Delegation is Allowed

Anyone with the right permissions in JIRA can move items into the current Sprint. However, this should only be done at the request of the Development Team. Scrum iterations are pull-based queues, rather than push-based, so nothing should be in the Sprint that wasn't approved by the Development Team for the current iteration.

It's obviously best if the Development Team has the ability to directly manage its own Sprint Backlog, but sometimes organizational policies or separation of duties can get in the way. If that's the case for your team, then it's okay to delegate the administration of the stories within JIRA, so long as actual control of the Sprint's content remains in the hands of the Development Team throughout the process.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

New contributor
olesyam is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

In the middle of the Sprint the responsibility lies with the Development team. They could pull-in/change scope after re-negotiating with the Product Owner. The Scrum Master can facilitate this.

This is what the Scrum Guide says about it:

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

https://scrumguides.org/scrum-guide.html#events-sprint

I think talking about it with common-sense and the full team is important. You want the Development Team to have focus and minimize adhoc-context switching, but sometimes the world changes and everyone needs to be open to adaptation.

But the Scrum guide suggest to cancel the Sprint when the scope is so big it would change the Sprint Goal:

A Sprint would be cancelled if the Sprint Goal becomes obsolete.

Your Answer

Mike is a new contributor. Be nice, and check out our Code of Conduct.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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