How to chose the right perspective in user stories?

Question

As a PO I plan to write user stories for a project. In this project, we'll send messages via email that should get formatted according to a style guide, as an example. What is the best perspective to write the user stories in such cases?

I, as a receiver of an email notification want to find my new messages all styled in a way making it identify them easily as sent by ACME Corp.

or

I, as the brand manager of ACME Corp. want to see all messages sent by email apply our corporate style guides?

Please note that this is just an example (don't waste your time on the email idea), I wonder which of the two perspectives is most useful for the development team that is going to implement my stories?

Answer 1

A key part of the purpose of a user story is to understand the need from the user's perspective. As such, you want to explore their need. This should be their perspective and focus on their need, not the solution. For example, I could write a user story that reads:

As a customer newly registered distributor for ACME Corp, I would like a confirmation of my registration emailed to me so I know that it went through properly.

It is also important to remember that not all backlog items must be user stories. I could simply say:

Reformat confirmation email to match new branding guide.

This sort of thing can be useful when you have to go redo something with a specific solution. Alternately, if I was going to do a new project with emails, I would probably include something in my definition of done that says:

All communication meets branding style guide.

and it would never be a backlog item, but would rather apply to all backlog items.

Answer 2

I wonder which of the two perspectives is most useful for the development team that is going to implement my stories?

In all honesty? None. Most useful is the conversation you (as the PO) have with the dev team about the user story, explaining them what needs to be done and what the acceptance criteria is for this particular functionality.

A one sentence long statement of what you want is usually not enough to understand everything that needs to be implemented. User stories are not detailed requirements. They express what the user needs the application to do for them. They are from the "user" perspective, that's why they are called "user stories".

Going on your example, my idea of an user story might go something like this:

As a user of the application, I want to receive relevant marketing emails so that I can profit from the best deals

... or whatever.

Nowhere in my example is there specified "how". How the email is formatted? How is the email styled? How is the email sent? These are part of the discussions the PO and the dev team need to have around the user story when it's time to implement it. As a user I really don't care about that, I just want the application to do it somehow. It makes business common sense for the email to carry your company's branding, but that's your acceptance criteria as the provider of the application, not necessarily mine as the user of the application (this shows another problem with user stories, sometimes they are not written by real users, but by someone from business who "thinks" they know what the real users want).

Then, not everything in the backlog needs to be a user story. How about bugs? Do you write bug issues from the perspective of the user? It's ridiculous, right? Somehow though, people try to force all features, functions, requirements, technical changes and implementations, etc into user stories and think it's OK to do that. But it's not. It just creates administrative overhead because instead of specifying what's needed in a natural language, then discuss further details based on that, people spend a lot of time to write "the perfect user story" on a constraining pattern. Sometimes that goes overboard and you end up with anomalies like "As a developer I want a back-end API so that I can implement a rich front-end", which is worded as a user story, but it's not a user story.

An item like the following is just fine:

All email communications to users should be properly styled/formatted

Don't overthink it. As long as everyone understands what it means and what needs to be built (which rarely is understood from just one sentence - thus the conversation you need to have), it needs not to be forced into a "As a [user type], I want [some thing] so that [some reason]" pattern.

If you find it hard to express it from the user's perspective, then maybe don't write it as a user story.

Answer 3

As a general rule user stories are written from the point of view of end-user value.

I, as a receiver of an email notification want to find my new messages all styled in a way making it identify them easily as sent by ACME Corp.

That would work if it is valuable to the end-user to easily identify emails.

I, as the brand manager of ACME Corp. want to see all messages sent by email apply our corporate style guides?

This wouldn't usually work as I'm guessing most end-users won't care if an email follows the corporate style guide.

It may feel like the brand manager is a customer for the user story, but in this case I don't think they are. This is because the brand manager does not get direct value from the story and is not a genuine internal customer.

There are products that deliver direct value internally. Say, for example, you were writing an internal application that let the marketing director coordinate their marketing campaigns. That is an internal product and so the end-user is an internal person.

Answer 4

I would recommend that you write user stories from the perspective of both users as both users have different needs but they are driven. I would then link the 2 stories so that the developers are aware.