Who should create the Product Backlog Items (User Stories)?

The Scrum Guide doesn't mention user stories at all, but it does talk about creating and clearly communicating Product Backlog items. It also says that the Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

The office cleaner could therefore write user stories if that makes best sense in a specific situation, but if they are inappropriate for product value optimization, the PO will carry the can.

In Scrum it's accountability that matters. The Developers are accountable for quality for example, so it isn't enough to "write" Product Backlog items, but to make sure they are sufficiently well understood by them for the Definition of Done to be met in a Sprint. That's why collaborative Product Backlog refinement is important.

I agree with Ian's point, a backlog refinement session with the PO and developers will be essential. Writing the story is something anyone can do; however the PO should be able to clearly communicate what is required. The PO is accountable for maximizing the value delivered each sprint, it does not essentially mean he is the one who should write each story. Let him communicate the product features and the value delivered and in the refinement session see how it can be split into stories which can be picked up during the sprint.

As a Scrum master you will have to coach the developers and the PO about their accountabilities and shared responsibilities. The PO can OfCourse delegate his responsibilities to someone (Business analyst or anyone), but the accountability lies with him/her at the end of the day

Thank you Ian and Anand for your responses, really appreciate your insights!

Having said that, these are all Scrum theory provided in the Guide. As it says that Scrum is purposefully incomplete, I just wanted to check on a practical perspective, how do we typically handle this situation. Backlog Refinement can happen effectively only if we have some 'token of work' (we can call it Story, Movie, Item, task, whatever we want) available in the system to base discussions on. 

Our Product falls nicely onto the complex domain of work owing to multiple third-party integrations it has and the intricate nature of financial complexities. The PO barely gets time to create all the Stories post having discussions with all the Partners and aligning them on the next Sprint's requirements. The Team, on the other hand, are still playing catch up with the Financial domain of the work & producing valuable increments in the Sprint.

Scrum says that the PO is accountable at the end of the day, to ensure PBIs are created & communicated clearly. However, I want to get some insights on how typically its done in cases where PO is not able to get enough bandwidth to do that all by herself and the Team is also struggling with the same (unless I ask her to stretch herself and make sure she creates all items in the System, come what may...)

What are those other things taking "bandwidth", and which rob people of commitment and focus? If there are other more valuable things for them to be working on, then the situation needs to be made transparent so expectations can be managed.

In practice, the rate at which work.is refined and completed for this product can then be reduced accordingly and in line with these expectations. When multiple things are being worked on simultaneously, remember to further allow for losses due to context switching.

I want to get some insights on how typically its done in cases where PO is not able to get enough bandwidth to do that all by herself and the Team is also struggling with the same (unless I ask her to stretch herself and make sure she creates all items in the System, come what may...)

I am curious to know if this issue has been brought up during the sprint retrospective. How does the team propose to solve this? 

I would suggest to may be ask the PO to write epics/ features which are high level and someone from the team (or the whole team) can break it down into user stories. Make sure whenever PO is available, ensure you end up having enough work for at least 2-3 sprints.

In the PO's absence, mature teams can themselves write stories provided the product vision is clear.

I was faced with similar challenges at a company that was trying to move away from waterfall and implement some agile practices.  @Ian's latest questions cut to the heart of our problem at that time.  Instead of letting the Product Owner and Developers focus on a single product, they were being pushed into a lot of other initiatives that took time away from working on the Product.  These initiatives were needed for waterfall project management but were not useful when trying to inspect and adapt frequently. We were able to eliminate many of those and "suddenly" the team became much more productive. 

I just wanted to check on a practical perspective, how do we typically handle this situation.

The simple answer is that everyone has to come up with their own answers based upon the situations and organization.  The Scrum framework is does not provide guidance on that level of detail.  That is because any organization that is relying on empiricism will learn how to adapt to the situation.  That is the heart of empiricism. When my kids were younger I described empiricism to them as "Do something, look at the results, think of how to change, do something again."  You have a problem.  Inspect the problem to find the reason that it is occurring.  Try something to address it. Then repeat that cycle until things become better. 

I have worked in organizations that used Business Analysts to help the Product Owner.  I have worked in organizations where representatives from the Support organization helped the Product Owner since they were in constant contact with the stakeholders/users.  I have worked in organizations where the Developers would write Product Backlog Items and then discuss them with the Product Owner.  I have worked in organizations that did all of the above. It all depends on the organization, the resources available to them, the trust that is shared across the organization and people. 

Do something, look at the results, think of how to change, do something again. 

My Scrum team works on a complex product for a financial services organisation.  We have a full-time BA that works alongside the PO.  The PO spends most of their time with stakeholders at a higher level, talking all things strategy and value.  The PO is responsible for creating Epics, Features, and skeleton PBIs.  The BA gets into the weeds, fleshes out the PBIs, and for the most part works with other members of the Scrum team during refinement.  We've found this works really well for us; both the PO and the BA know the product intimately and have good a relationship with the stakeholders.  We have enough going on that the BA is permanently part of the Scrum team, this is their full-time job.

I hope that helps.

Possible another option. When complex uncertain work was encountered, the team would define a spike that gives the developers a chance to investigate more. This investigation can be to develop a prototype, investigate the existing code and try to extract new insights or do a design investigation from theory. The spike is time-boxed, and information gathered during the spike helped the detail needed when refining the user stories.