Schedule a Call

Choose a time that works for you.

Loading calendar…

If it does not load, Open Calendly directly.

Selecting the Right User Role

When writing user stories, one of the first considerations is who to write the user story for. Despite the name--user stories--it is sometimes beneficial to write stories for someone other than the user. No, I don’t necessarily mean we want a bunch of “programmer stories.” Those are generally best avoided. Rather, I’m referring to writing what we may want to call “customer stories.”

As an example, I am currently working as the product owner on a website that will include display ads on some of the pages. I could write stories such as:

  • As a site visitor, I want to see ads so that when I click on them the site owner makes money and is able to continue funding the site.

This is a valid story but it’s pretty far from something a user really wants. It sounds false to me. Even though it’s not a true user story, I would prefer to write:

  • As the company owner, I want ads on the site so that I make money when users click on them.

That certainly has a greater ring of truth to it! If you don’t like company owner, I think it could just as well be the company, product owner or anything like that.

A similar question I was recently posed had to do with a company selling prepaid gift cards. Should user stories here be written from the perspective of the card holder redeeming the gift or from the perspective of the company that accepts the card.

  • As a merchant, we can accept gift cards for all transactions

  • As a cardholder, I can redeem a gift card at the store through which it was offered. (There could be additional complexities here as cards could be to a specific mall, rather than store. But those complexities aren’t important to this discussion.)

I consider these stories to be semantically equivalent. Neither one tells me any more about the cardholder’s goals. So I think either works. There will, however, be some related stories that seem better one way. For example, consider these:

  • As a cardholder, I can check the balance on a gift card by asking a clerk at the merchant.

  • As a merchant, I can inform a cardholder of the remaining balance on a gift card.

Although either of these could work, I have a slight preference for the first one because it cardholder is the initiator of the action of this story. I’d like the first story even better if I could make it more general:

  • As a cardholder, I can check the balance on a gift card so that I know how much I have left to spend.

And then add conditions of satisfaction to the story:

  • Must be able to check balance online by entering the card number

  • Must be able to check balance in a store by having a store employee swipe the card through a POS terminal.

  • Balance must be updated real-time.

So, while it’s important to think about the best user role to embed in the story, I find that most of the time the user is quite obvious. When it’s not, spend a little time thinking about the options and choose the one that feels most natural and best conveys the desired action.

Explore Further

Article artwork for User Story Template: What It Is and Why It Works So Well.
Article

User Story Template: What It Is and Why It Works So Well

Featured

Understand why the three-part user story template works and where it falls short.

Article artwork for How Detailed Should a User Story Be?
Article

How Detailed Should a User Story Be?

Featured

Capturing too much or too little detail in a user story causes problems. Here's how to get it right, iteratively.

Ax splitting wood to illustrate splitting user stories.
Article

SPIDR: Five Simple but Powerful Ways to Split User Stories

Featured

Splitting user stories is hard. Here are the only five techniques you need to be able to slice any user story into small, manageable chunks of work.

Article artwork for Relationship between Definition of Done and Conditions of Satisfaction.
Article

Relationship between Definition of Done and Conditions of Satisfaction

Clarify how Definition of Done and conditions of satisfaction work together.

Article artwork for Job Stories Offer a Viable Alternative to User Stories.
Article

Job Stories Offer a Viable Alternative to User Stories

As useful as user stories can be, they’ve never been right for every team. An exciting alternative for some teams is the job story.

Mike Cohn answers team questions about acceptance criteria, so-that clauses, and requirements vs user stories.
Article

Short Answers to Your Big Questions about User Stories

Get quick answers to common questions about user stories and acceptance criteria.