8

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?

  • 1
    If you are reading this site, and your product owner is not, then the job of the product owner is being done by people who do not have the 'product owner' title. If they do not want to get into their job responsibilities, then best for your org. to assign the duties to someone else who does. If these problems continue, hopefully your "product owner" or their boss will be reading this feedback. Tough love makes ways – New Alexandria Jun 24 '14 at 12:35
  • 1
    I think this article has some very practical examples where having the Product Owner as the user role would be appropriate. mountaingoatsoftware.com/blog/selecting-the-right-user-role – Ryan Howard May 19 '15 at 21:22
18

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.

6

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.

4

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

  1. Card
  2. Conversation
  3. Confirmation

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 :

  1. As an admin, I should be able to (ISBAT)...
  2. As an employee, ISBAT..
  3. As a premium user, ISBAT..
3

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 ... .

1

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.

  • Thank you for the PO perspective. This kind of thing comes up a lot and a question I often ask is "Does the As a ... I want ... So That add some value here?" It isn't a user story (no user involved) and Scrum doesn't require that all items in the backlog are user stories, so why not just have a backlog item that says "explore feature possibilities"? – Daniel Feb 8 at 13:44
0

Some stories can be written only from the point of view of the Product Owner

Let me give a couple of examples:

  1. 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).

  2. 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.

  • Are you are confusing stakeholders and POs? – Sklivvz May 15 '14 at 15:25
  • @Sklivvz In a smaller company I worked for earlier, the Product Owner had the final say on analytics, branding and such. No other stakeholders. – Ashok Ramachandran May 16 '14 at 20:03
  • 2
    It's entirely possible for a PO to be a stakeholder as well, but they should differentiate the person from the role. If a PO controls branding, the story should still be about marketing: "as a marketeer I want the logo to be more prominent so I can increase brand value" makes sense; the same story "as a PO", not so much. – Sklivvz May 16 '14 at 20:08
  • I feel like this is based in an assumption that a user story is the only took in the tool box. I wouldn't use user stories for either of these two cases. – Daniel Feb 8 at 13:41
-1

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

  • 1
    Hi Carl! Thanks for taking the time to write this answer :) This is a list of examples, but does not answer the question. Could you perhaps consider making your point more explicitly before listing examples? – MattiSG Jun 25 '14 at 12:48
  • Your question is broad but the example i gave are how they should be written, in a way so that dev team, end users, product owner etc... can understand. The example are for a student IT job search website me and some others made. – Carl Blance Jun 25 '14 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.