We "teached" our product owner to write user stories using the template "As a ... I want ... so that ..." (see http://en.wikipedia.org/wiki/User_story#Format) . However he/she is now writing the user stories like
As a product owner I want ... so that ... .
Is this a way how user stories could be written?
No, they would only make sense if you were writing a product where a "product owner" was a customer -- for example, a tool for keeping a backlog would have stories that start with "As a product owner" because a product owner would actually be using the product you are developing.
But normally, no. The product owner is generally not a customer/user of the product so it doesn't really make any sense.
Generally speaking, the product owner is the stakeholder representative and voice of the customer. I would expect the user stories that they write to identify which stakeholder or customer group (or groups) are impacted by the story. Because the product owner can be considered a stakeholder, though, I don't see the issue with stories written from the perspective of the product owner or even the development team. Without an understanding of the project and taking each story into individual consideration, I'm not sure that someone can say if it's well-written or not.
We should always write stories from the perspective of user role you are catering to. The user stories are the foundation to 3C's. Reference Link
Card : This is to write user stories which will help the person who will be using the feature. This explains what the user wants in simple words.
Conversation : The user story written on the card should be a conversation starter among the team including customer. This should ideally happen before development starts for a feature. This conversation is useful to figure out what the end user of the feature is trying to solve.
Confirmation : As part of the conversation, acceptance criteria (and ideally, "examples" ) are also discussed and documented. Once the story is coded, these criteria are used by the customer to "confirm" that the story can be "accepted" and pushed to production.
Writing the user stories with "end user perception" will also make the team/customer think of possible scenarios in the real world. This will eliminate possible scenarios that can be missed if we do not keep the users' roles in mind.
I would prefer to write the user stories as below :
Product Owner is the name given to a role which is specific to the process/framework you are using to manage the project or to execute software development. This particular name has no meaning outside the context of this process. The system which you are trying to build will have its own specific users. Each of those real users may have a different expectation, different usage, different value to be derived from that system. So your Scrum team (including the Product Owner) should identify the real users of the system and write stories from their perspective.
Keep in mind that, for the intended system, real users and company roles (or job titles) are two different things. For example, two persons can have the same title "Customer Sales Representative", however one person could be handling inbound queries and the other could be making outbound requests. If they will be the real users of the new system then expectations and usage of these two types of users could be different from the new system. If that is the case then your users stories should be written separately, some stories will deliver value to the "inbound representative" and some stories will be for the "outbound representative".
This approach will give a clear picture to the team about why are they adding a particular feature to the system. Team will be able to connect the real user with the story goals and its benefits thus creating a sense of empathy with the actual user. Team understands the "bigger picture" of why they are implementing a task which they have been asked to do.
So to your question, no it is not appropriate in normal situations to write stories like As a product owner I want ... so that ... .
One thing that I'd like to add as a product owner.
Sometimes, when a design is needed, I'll write the story like:
As a: PO I want: a design for feature xyz so that: further work can be identified for implementation of xyz
Usually, that'll get assigned to an architect on the team. That's usually the only time I use the "as a PO" though.
Let me give a couple of examples:
Analytics stories: The end users of the application do not care whether you collect any analytics data at all. In fact some end users may not want you to collect analytics data because of privacy concerns (rightly or wrongly).
Branding: End users care about usability. But they do not care about whether the company's brand is displayed more prominently or whether the color scheme aligns with the branding.
But the Product Owner does. So these stories can only be written in the format of "As the Product Owner I want...". The Product Owner represents the interests of the business, which sometimes may have to override the interests of the end users.
However, you want to be careful not to use the Product Owner as a proxy for end users. Because you can potentially write every story from the point of view of the Product Owner. Make an effort to identify who truly wants a feature and why. Making this extra effort to think through who wants it and why will help you to:
drop some stories that do not really add value to anyone.
enrich the stories by writing the relevant acceptance criteria.
Here some examples I pulled this template off scrumalliance.org and its worked nicely when I've adapted it
User story in front, acceptance criteria at the back
First Example
As a student
User stories title: Student registers I want to register with on the website So that I can view and apply for IT jobs
Acceptance Criteria: Given that the students ID is valid in the system When the student first enrolled at the campus Then the student will register with email validation
Second Example
**User stories title: Students edits profile** I want to edit my profile on the website So that I can access everything a student user can and apply for jobs
Acceptance Criteria: Given that the student has registered and logged into the website When the student validates his account using their email Then the student will have access to everything a student user can access
Third example
As an employer
User stories title: Employer registers on the website I want to register on the website So that I can list job vacancies for students
Acceptance Criterion: Given that their login details have been given by ****** administrator When the employer has first contacted **** IT administrator via email or phone Then they can list job vacancies for students
Fourth Example
User stories title: Employer post jobs on the website I want to post student job vacancies So that I can hire one or more students
Acceptance Criterion: Given that the employer has access to the website When they want to post a job vacancies Then the employer can list position details and requirements for the job
