Quick public service announcement regarding user stories.
A Product Owner is not a user
A Development Manager is not a user
A Developer is not a user
A Tester is not a user
Only end users of the system are users, and yes that includes service / help desk users who need to investigate things.
Would love to hear opinions
As tester I’m not a typical end user, but I appreciate user stories which start with “As tester I want to have X (e.g. logging) in the system so that my analysis and testing are more easily doable”.
As tester I’m a user which demands test-ability of the system.
I think this is more in the direction of your mentioning of service / help desk.
But its me being mostly not working on the productive system but the test system.
I agree on that especial Product Owners, but also the other roles, should not be used because of laziness.
Surely a PO writes the user story.
But it should be written from the perspective of the final user.
Also I have this idea, but I can not come up with a good example:
I would say that also the bosses of the end users are also a type of users.
They want to achieve something with the system. Very often it should somehow generate yield. Maybe also the enforcement of certain regulations.
Should this maybe happen at an earlier step ?
If I want to enforce a regulation I have to write the user story in the way that.
I wonder what the user story at the Taylor Company for the McDonalds Ice Machine sounded.
“As Taylor Company manager
I want the McDonald’s ice machine to often get broken during the cleaning
So that McDonalds needs to call often our technician and we can charge them high prices for that.”
This vicious cycle will continue until the employees finally give up and call a technician. Now, this is the part that’s going to start sounding like a conspiracy theory, but we promise (we hope) it’s not. The only technicians that McDonald’s franchisees are allowed to use to fix the Taylor Company machines are Taylor Company technicians.
Some people go as far as to say that Taylor designs these machines to be faulty, so it can charge extra for more repairs. While that can’t be proven, it is true that Taylor rakes in a large amount of extra cash for performing these repairs. In 2018, the company’s own acquisition review stated that 25% of revenue came from “recurring parts and services business.”
Shall I continue with gambling and other manipulative products?
Well my answer is …It depends.
For me a Product Owner or a PM is a user but it does depend a lot of the context and of the application.
If you have applications that are open to the public then you can really say that any person that can open the application is a user.
If you have applications that are very service specific ( accouting, healthcare etc) then your actual user needs experience on the subject to actually use the application.
But to say a few words about “A tester is not a user” I would have to say a tester is all users in one.
I consider both the same.
Someone using an online shop is a user as well as someone doing accounting.
Despite that online shops feel quite natural to us, our situation of being used to them comes from experience we build up. We have a bias here.
I have children and see how much they do not know or can which feel “normal” for me. Which I have to teach them.
Put a child / elder / whoever-is-not-used-to-only-shops in front of one and they are “lost”.
I would rephrase it like this:
A tester should try to represent all users (which are worth to represent).
In this representation situation the tester acts as one of the users of the system.
But this no reason to start a user story “As tester”.
To relate to my previous comment:
A user story starting with “As tester” is only valid as long as it is about the specifics of testing (e.g. improving test-ability of the product).
At the very last:
Testers demanding changes for their craft at the product are different users than end users.
I’m curious about your response. 
(or anyone else reading here.)
(Yes, YOU!)
(Yes, YOU!)
Okay.
Call them “role stories”. Solved.
I also think we shouldn’t over-invest in the detailed taxonomy of tool instructional manuals and just use them however we want. Unless you love categorisation, in which case enjoy yourself, but don’t confuse organisation with utility.
In my experience, everyone has it wrong at least sometimes.
Saying what they want, expect, and mean explicitly (not even in writing but just to keep the same thread going from time to time) can help in some cases.
I see you have asked a new question.
What do you say about the comments here?