We have the most of our PBI in user story format:
As a [user], I need [requirement], so that [reason].
I need to write some requirements affecting directly to the product but not exactly to any user, but necessary to achieve the product. In this case, could be the product owner as another user in user stories?
The only time the Product Owner would be named in a user story is if you are building a product that is designed for Product Owners.
I need to write some requirements affecting directly to the product but not exactly to any user, but necessary to achieve the product.
Will users of the product really see no value at all from the requirement? If that is true, why are you wasting time on it?
Even non-functional requirements can be written in the sense of a user:
As a user of the product I want it to be responsive even under heavy load so that I get a good experience
As a user of the product I want to be sure that in the event of a hardware failure I do not lose any of my data so that I do not have to waste time re-entering it
As a marketing executive I want to see statistics on the use of the product so that I can quickly make decisions about marketing campaigns
Try and avoid making technical tasks in to user stories. For example:
As a Product Owner I want a database to be created so that we can build the product
Instead, wrap these requirements into a real user requirement as sub-tasks.
For example:
As a user I want to be able to login to the product so that I can access its features
This is the first story the team is doing and to achieve it they might have sub-tasks that include: create database schema, build database, setup database server, setup application server, create authentication framework etc.
Two things come to mind.
First, if you can't trace the need to a stakeholder impacted by the system, is it actually a requirement? Unnecessary features and gold-plating is a waste, in the Lean sense. However, just because you can't trace it to a known user class doesn't mean it's not valid - it could be hard to express some non-functional requirements, infrastructure related tasks, or regulatory/compliance requirements in the User Story format.
Second, if it is a valid requirement on the system, does it need to be expressed as a User Story? For non-functional requirements, consider using the Definition of Done to assert how the system should be after implementing any story. Security requirements, performance requirements, usability requirements, and others may be best expressed in this way. In other cases, it may simply be something that needs to be done to enable other work - don't unnecessarily constrain yourself to the User Story format.
Unfortunately, without seeing the specific requirement that you want to express (and perhaps a deeper understanding of the system under development), it's not possible to say which category your requirement falls into - an unnecessary requirement or one that should simply be expressed in a different way.
Sure, the Product Owner can be a legitimate role in a user story. So can a Developer, or a Sys Admin, or so forth. The key thing is to identify the role who will benefit from the business value delivered by the goal. In other words, don't just default to the PO as an alternative to "user".
Sometimes it's easier to go up a level to find the appropriate role. So maybe you have an epic:
As a (role), I want the product to be archivable so that (business value).
That story might be completable in various ways:
As a sysadmin, I want the product to be archivable so that I can make backups and restore them in case of catastrophe.
As a contract officer, I want the product to be archivable so that I can hand over an archive of it to comply with a contract deliverable.
Once you clarify the business value of making the archive, the role should become clearer. If the conversation with the PO is difficult, I might try "can you tell me what you are going to do with the archived product once you have it?"
