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.


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?

  • The “user” is the value consumer. In this case the person receiving the value, and who is able to hold a conversation about the specifics, is the brand manager. A longer answer may be forthcoming, but in most cases the “user” in a user story is the person you can collaborate with or the key perspective you need to consider in your solution. In most larger systems, this isn’t necessarily an end user.
    – Todd A. Jacobs
    Jul 28, 2019 at 20:14

4 Answers 4


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.

  • I agree to all of your statements, but I am not sure if they really answer my question. Let me rephrase it to "Who is the user here with some need: Is it the actual receipient of the message (who probably does not really care about the formatting), or the brand manager (who wants do see his rules obeyed)?" Jul 26, 2019 at 18:29
  • Rule of thumb: The user is the person consuming the product, not the one creating it. When it comes to brand management, the manager doesn't get anything except a paycheck out of it, so it's hard to argue that they have a need in it, so if I had to pick one, it would be the recipient. However, the need here is so abstract that I don't see how using a user story format adds any value.
    – Daniel
    Jul 26, 2019 at 18:35
  • In truth, the real recipient of value is the company - or if you want to be technical, the shareholders, because brand health is more of a long-term company investment. Again, the user story is a poor tool for expressing any of this in this particular case.
    – Daniel
    Jul 26, 2019 at 18:36
  • Exactly. Branding can also be a part of acceptance criteria. Aug 22, 2019 at 9:22

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.

  • I agree to your reasoning, even if it broadens the scope of my question a bit. Jul 28, 2019 at 9:40

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.

  • What made me ask is the question if things like compliance to some standards is a business value by itself. Jul 28, 2019 at 9:33
  • I have in the past had a compliance based story. It went something like: "As a compliance manager I want the application to be compliant with banking regulations so that we cannot be fined". I think this is legitimate as it is not a 'means to an end', but a concrete internal requirement that has no impact on the organisation's customers. Jul 28, 2019 at 12:16
  • @NilsMagnus Business value is different than value to customer. Having a legal team is a business value, but pointless to the customer. User stories are written with "value to customer" in mind. You can definitely consider "business value" as one of the aspects to your prioritization formula. Aug 22, 2019 at 9:25

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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