Best Practices for prioritizing Jira tickets as a Product Owner – Seeking advice from the field
Hi everyone,
I've been struggling for months to find groups where I can join and have spoken exchanges around the challenges of working as a Product Owner. I currently work in a company where I deal daily with a team that calls itself the Development Operations team, which also includes the Scrum Master.
Unfortunately, we face some internal challenges:
- The number of technically capable resources is limited
- Two team members are not developers and tend to work slowly on Jira tickets
- Two architects are quite rigid and strictly stick to their own defined processes
- The Scrum Master, rather than acting as a neutral facilitator, tends to represent that team’s interests, given her involvement with them.
That said, the main purpose of this thread is to ask for best practices around how to prioritize tickets.
We use Jira, and the current situation looks like this:
- I prepare the sprint in advance with tickets that have been discussed with the business and prioritized. The ordering goes as follows: first the bugs (based on their severity), then the change requests (also sorted by priority). If two tickets have the same priority, I personally don’t mind which one the developers choose to tackle first. I also make sure that the items meant to be implemented right away are at the top
- Despite this, developers often ask me again which ticket they should start with first, even after I've prioritized and ordered them clearly in the sprint
- It’s difficult to reach a fair agreement with the business side about what truly is a priority—everyone says "my ticket is important and needs to be done now."
- Tickets with multiple story points (e.g., 3, 5, or 8+) often get pushed from one sprint to the next because a resource starts them but is only available for 1.5 or 2 days across the two-week sprint—or the Scrum Master assigns them to someone whose availability is very limited, or says “this person won’t be available for the full sprint.”
- Some topics require input from a SAP team that unfortunately does not work under Scrum methodology. Even when we mark a ticket as high priority, they do not take it seriously, and months can pass without any progress
- This Operations team and having the SM as head of them says that I am teh contact person for them and not the business when a ticket does not make progress because the SAP team does not make any advance with a JIRA ticket
So, I would love to hear how you all prioritize your tickets.
What are some best practices to keep in mind?
Since I’m still fairly new in the company, I don’t yet have full visibility into all business processes—and honestly, no one understands the business impact of a ticket better than the business stakeholders themselves.
I appreciate any constructive feedback or shared experiences—thank you!
My advice is to refine the Product Backlog with the Developers, so meaningful Sprint Goals can be identified in future Sprint Planning sessions. Work that requires external parties for completion might never be ready in so far as the Developers cannot commit to Done, and transparency over this issue will need to be established. Avoid using the Product Backlog as a list of stuff to be somehow worked through, and use it to feed innovation.
I have seen your posts and can relate to your struggles. I've had many of them myself. I have never held the job title of Product Owner/Product Manager but I have done the work described for it in the Scrum Guide on many occasions. I know this might be going against the "rules" but I have found that this forum and a couple of subReddits are the place where I get the most useful feedback. Sure, you get to deal with some noise but even that can be useful in the empirical sense. I have also had some people contact me directly through LinkedIn and will discuss things with them there, as long as they understand that I am just giving them my opinions and anything I say should be examined for applicability to their situations.
The best way that I have found to organize an Product Backlog is similar to what @Ian says. Remember that you don't want to prioritize the backlog. You want to order the backlog. And according to the Scrum Guide:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
That is the golden rule. You order the backlog so that the work that the Scrum Team can do provides the most value of the product to the stakeholders. If there is something that is "wanted right now" but it can't be done "right now" because of dependencies then make that clear to the stakeholders and find things that will provide them benefit in other ways until such a time that "right now" becomes possible. The Scrum framework provides guidance on how to make it possible to adapt quickly so that value can be continuously delivered. The drive for transparency of the work leads to making things apparent to everyone that has a stake in the work. Sometimes that transparency makes it uncomfortable for others but it also provides the catalyst for change.
A stakeholder does not have to be a customer. They do not have to be someone that pays you money. Stakeholders that are often overlooked are the other products or organizational groups that need your work in order for theirs to be valuable. In this case, your SAP team is a much a stakeholder for you as you are to them. Without the work of the two groups, the word done by one group can not provide full value. So, working on ways to cooperate becomes crucial. So if your other stakeholders are not able to get the value they need from you because of the SAP team's actions, then your other stakeholders need to know this and apply some pressure on the SAP team.
Thanks for sharing your situation — I can definitely relate to some of the challenges you’re facing. It sounds like you're doing your best to keep things structured and prioritized, even with the complexities around team dynamics and limited availability.
One thing that’s helped me in similar situations is making the prioritization process more collaborative and transparent with both the team and stakeholders. For example, bringing the business stakeholders into a regular refinement or prioritization meeting helps make them more aware of trade-offs and encourages shared ownership of priorities.
As for the team asking again which ticket to start with — that can be frustrating. Sometimes a visual signal (like a clearly marked “Start here” label or a short Loom video walking through the sprint backlog) helps reinforce what’s already there in Jira. Also, if capacity is always shifting, maybe try adding a quick “effort vs. value” matrix before each sprint planning to help guide who takes on what based on availability.
And for the cross-team (like SAP) delays — it might help to escalate those dependencies during sprint planning or in your review/retrospective, so there’s visibility and maybe some pressure from leadership to move things along.
You’re doing great — prioritization is as much about people as it is about process. Keep going! 🙌