How to Handle Resource Shortages and Overlapping Responsibilities as a Product Owner?
I have the following situation. I'm in a company that, unfortunately (at least that's my impression), is reluctant to invest in more personnel to join the development team. The development of the product backlog items is slow.
As a Product Owner, I sometimes receive requests from the business side to grant them permissions to delete, view, or create records in the application. This is more related to the administration of the CRM software we are using. I spoke with the Scrum Master about a request from the business side in this regard and created a high-priority ticket for it. I was surprised when the Scrum Master told me that they would then have to remove a ticket that was already planned in the sprint planning to replace it with this one (the business request), since the development team is overloaded.
And with this overload situation, we are stuck in every sprint, unable to move forward as we would like. I then offered to handle the ticket myself to relieve the development team, even though I believe this is not my role as a Product Owner.
What should I do in this case? Have you ever experienced a situation where there is a lack of resources and development is very slow, while software administration tasks also overlap? I was always used to having a separate team, like a CRM Software Desk, to handle these administrative tasks.
I have already discussed this issue with the managers, but I am not getting support (in terms of more resources). I am new as a PO and sometimes I don't know what is valid and what is not in this situation. How should I address this problem?
Do you recall any discussion about whether this change would help the Developers to better meet the Sprint Goal, or if it might put the Sprint Goal at risk?
I don‘t understand what you mean.
As a new PO, it’s normal to feel uncertain about boundaries. What’s not valid is the expectation that you should routinely step outside your role to compensate for understaffing. What is valid is advocating for the product and the team, even if it means having tough conversations. You’re not overstepping by asking for resources or clarity that’s part of being a PO.
Next Step:
Start by having a candid chat with your Scrum Master about protecting your role and brainstorming team-level solutions.Then, bring data to your next manager discussion to keep it objective. You might not get more headcount, but you could negotiate a shift in how work is distributed.
I don't know what CRM you are using but if it is that much work to update some user's permissions, then I don't think I would ever use it. I say that because you make it sound like the Developers have to remove tickets from the Sprint Backlog to make those changes.
I have been administrator for many of the tools we used in the places where I worked. I had many job titles while I did this but none of them was ever "CRM Admin". I did it in addition all of my other duties because it was not difficult and took very little continuous time. It allowed me to enable my team and others to be self-organizing and self-managing by opening them up to have more permissions.
My take is that if you are the Product Owner, you should have as much access to the CRM as possible for you to be able to maintain the Product Backlog. If that means that you get admin permissions, even if just to your project, then you should. Then if someone else wants to have access to help in administrating the Product Backlog, you can decide. This is from the Scrum Guide's section that defines the Product Owner accountabilities.
The Product Owner is also accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
NOTE: Remember that the Scrum framework does not define job descriptions or job titles. It defines 3 sets of accountabilities that need to be owned by individuals in order for the framework to succeed. I suggest you use that as much as possible to enable you to do your job and aid your team.