On This Page

A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF

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.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.