NEW PRODUCT OWNER

Firstly, your SM needs to serve the organisation by doing the following among other things: 

• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
• Removing barriers between stakeholders and Scrum Teams.

Secondly, if a PBI has been in the PB for ~2 years, does it really provide value for the product and is it still wanted.  You may wish to include removing old PBIs from the PB during your refinement sessions with the Developers.  If the value is requested again, a new PBI can then be created. 

going forward any requests I get my answer is going to be no unless it's something urgent or has alot more value than other items next up in the backlog. Does this sound like the right approach or is there anything else that might help me.

I'd suggest that there are stakeholder relationships to be managed and collaborative workshops to be held. This should involve more than requests followed by yes/no responses, which sounds more like a recipe for blunt trauma than the understanding and optimization of value. Remember that a Product Backlog is something to be tended and curated.

What I believe could help you is a clear Product Goal. A kind of a document that describes what your system is going to be and - equally important in your context - what it is never going to be, what functions will never be implemented in your system, what you consider out of scope. Where are the boundaries of your system.

The Scrum Guide:

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.

The Product Goal should be made transparent, in other words it should be communicated to the stakeholders.

It is definitely a good advice to sit down with the Developers and review all existing PBIs. Some of them could represent low value, others could be prohibitively expensive to implement. Usually, the Developers know more about the project than you think they know.

With a clear Product Goal and input from the Developers, you should work with stakeholders to remove some obsolete or irrelevant PBIs from the Product Backlog. You will have to negotiate.

The Scrum Guide again:

The Product Backlog is an emergent, ordered list of what is needed to improve the product.

The Product Backlog is not a storage for all Change Requests. It is not a parking lot for all improvement ideas. You don't have to accept everything and always add it to the PB. Only the items that are within boundaries of your Product Goal and that are needed to improve the product!

It is right approach not to accept every new idea but only these representing significant value for your organization. But you have to be open and transparent with your stakeholders. You have to give them justification. "Listen, this Item is on the Product Backlog for 2 years already. You may have an impression that we are working on it and that it would be delivered one day. This is not the case. We have many other PBIs that represent higher value with lower effort to implement. We will focus on these other items instead. I will take your Item out of Product Backlog in order to make situation transparent. One day we may return to your idea, but for now we are not going to work on it". "I spoke with Developers. Your idea is interesting, but it brings very little value for the organization and it is hard and expensive to implement. It has very low ROI. I will not accept this as a new Item on the Product Backlog. We would not be able to deliver it in reasonable time frame". "Your Request For Change is outside of what we have defined in our Product Goal document. Our system is not built for that purpose. We will review the Product Goal periodically, if your idea will fit into new scope then I will come back to you for discussion".

Focus - your role is to help the Developers to stay focused.