Open questions for experienced Product Owners
I am a Product Owner beginner and still with open questions regarding what a Product Owner normally does in following situations, where I would really appreciate for sharing from your experience as Product Owner :) :
- Is it valid for the Scrum Master to create a JIRA ticket for the next Sprint when the ticket has not yet been analyzed to determine whether it really has the priority assigned by the key users, for example, "Prio High"?
- As a beginner, I thought it would help me to add JIRA Tickets, Bugs, or Changes as a kind of table to assist in prioritizing tickets. This table would have to be filled out by the key users and would include fields such as: "How many users are experiencing the issue?", "Is there a workaround?", etc. Many users have their own definition of what "Prio High" or "Highest" means, and since they are the ones creating the tickets, they assign the priority themselves, which often does not align with the actual priority criteria. Has anyone here added something like this to a JIRA ticket for key users to fill out so that the PO can determine the ticket's priority? Or do you talk directly with the key users?
- Some key users have expressed their desire to create dashboards or reports in JIRA to display KPIs, such as the number of open and completed tickets. Would this also fall under the responsibilities of the PO?
- How do you plan the tickets for the next sprint?
- We have the issue of limited resources and budget to hire more people. Additionally, the current resources are unable to proceed because they require support from specialists in other systems (e.g., SAP), and those working with SAP do not use Scrum and are occupied with other projects. What can be done in this situation? Let's assume we only have resources available for 30 hours per week (Sprint every two weeks).
- Which tickets move to the next Sprint? Which tickets go to the Sprint backlog?
- When is it advisable to have a Sprint longer than two weeks (e.g., three weeks)?
- What happens if a developer goes on vacation and is the only person who can resolve a ticket, causing progress in the current Sprint to be blocked?
- What statuses should tickets have to be moved to the next Sprint? What statuses should they have to remain in the Sprint backlog?
Tickets aren't moved into the next Sprint. Product Backlog items may be selected by the team during Sprint Planning if they would help to meet a coherent and valuable Sprint Goal. Those items would then represent a forecast of work for the Sprint.
Items can only be selected if the Developers consider them ready for Sprint Planning, meaning they have been refined, and the Developers are satisfied that they can meet the Definition of Done for that work.
Thanks for your response, but what happens then with user stories, bugs, changes that could not be complete in the current sprint and the next sprint comes and you as PO have to plan the next sprint?. I mean what is best practices to say "this ticket goes to the next sprint because...". You have tickets with priority and with statuses...and happen then with the ones that are not completed, wouldn't they be part of the Sprint backlog instead of the Product backlog?.
While a tool such as JIRA might automatically move unfinished work to the next Sprint Backlog, don't let the tool force you into bein a mechanical Product Owner. Unfinished work in Scrum goes back to the Product Backlog, and a Product Owner needs to make a tough call - should we continue to invest budget in these unfinished items or has something other product Backlog it become more important?
Every Sprint is a fresh start. Did the entire Scrum Team reflect on the past Sprint as to why there was unfinished work? The new Sprint starts with a fresh Sprint Goal the Scrum Team crafts, and then self-managing Developers collaborate with the Product Owner on what to select for the Sprint Backlog.
Some key users have expressed their desire to create dashboards or reports in JIRA to display KPIs, such as the number of open and completed tickets. Would this also fall under the responsibilities of the PO?
Open and completed tickets are not KPIs related to business outcomes. Those are outputs. What if the Scrum Team completes 100% of their "tickets" every Sprint, but their work has dissatisfied end users, leads to revenue loss, poor quality, and heavy technical debt? Would those so-called KPIs then matter?
One short advice-pass all this questions to the team on the next retrospective, and allow some time to mutually figure this out. Involve a Scrum master. If time box does not allow coming to mutual agree this out in one retrospective, move it to next one.
As a product owner focus on value, product goal and road-map, and better identification of Current Value, Unrealized value, time to the market and ability to innovate.
Let scrum master and the team exercise themselves into better maintenance of Sprint backlog and refining the PBI's("tickets"). Don't expect some silver bullet to fly and suddenly shoot the team into perfect maintenance of backlog and sprint goal. It is more like bodybuilding through fitness-slow and consistent process where improvements are added day by day... You can use steroids like AI or do it all by your own with a team, but solution wll come slow
The last world: scrum theory does not provide an answer how to maintain backlogs, meet sprint goals or handle backlog items(which you call tickets). There are 1000001 scenarios of doing that based on composition of your team, character knowledge, temper and their opinion of Scrum. scrum is juts setting goal posts for achieving things, but it is entirely up to you and your team to achieve it, and the sooner team will find OWN way to handle this (through storming, norming and performing if necessary), the better.
And to make a long story short—stop creating 'tickets' (PBIs) for the team or planning the sprint for them. Just stop. Not only is this NOT the product owner's job, but it is also counterproductive to achieving self-management and good sprint planning by developers. Just stop thinking about this, and focus on the value they create each sprint and the increments they add, making sure it is happening according to the Definition of Done. Build better relationship with stakeholders, and reach to the market and end users, make sure the product is well defined. Let developers and scrum master refine the PBI's and handle backlog, just make sure to present a concept which brings value to stakeholders every new sprint
I respectfully disagree. In my opinion, you need a well-defined backlog in order to align work with stakeholder needs and market reality. When the PO contributes to crafting PBIs, it isn’t just about micromanaging the team; or it’s about providing clear strategic context. This entire idea is to ensure collaboration and that helps every ticket directly, which then ties into the overall product vision, empowering developers to self-manage effectively without losing sight of the bigger picture.
In general it is entirely up to PO how to manage product backlog, but to align with team it is better idea to involve others in this, at refinements or otherwise. Having elaborative PBI's based on some empirical evidence is always better then using personas or simply making up product backlog items