Analyst’s corner
Published in

Analyst’s corner

An open book with pencil drawings of a sailing ship and a palm tree emerging from the pages. The words “User Stories” are superimposed over the whole picture.

The Anatomy of a User Story

As a Product Owner, I want to understand why we use the common User Story format, so I can write effective stories that my team can use to develop products my customers love!

In this article we will get into the detail of the three elements of the standard user story template. The goal of this article is to give you confidence that you are using the most commonly used user story template correctly and to give you the knowledge you need to vary your approach to handle non-standard scenarios.

As you probably know, the most commonly used user story format is “As a…, I want…, So that…” so I will walk through each of the elements in turn; so lets start at the beginning with the “As a…” part of a user story.


The “As a” clause should be followed by who the functionality is for. When stating the user it should be as specific as possible. Take these examples

As a Company Accountant”

As John Professional”

As a system super user”

The Company Accountant example is using a job title as a short cut to identify the end user. We’ll assume that John Professional is a persona, or a fictional character created to represent a particular class of end user. The super user example is an example of a class of end users based upon their usage of the system.

Each of these examples could be a good description of the user of business functionality but it really depends on the organisation; you should aim to be as close to real humans as possible.

Sometimes people muddle up market segments with users of a product. For example, a Young Professional is a representative class of person and could represent a market segment, however, it doesn’t really tell us who the user is. It might be better to think of them as being a real person, such as a Teacher, who happens to also be a Young Professional.

Take a moment to think about some possible users for the following scenarios

  • A user who wants to listen to an internet radio station.
  • A user who orders clothes online.
  • A user who works for the police and searches police databases for stolen cars

Take a moment to write down some ideas…

Go on…

Ok, lets see how you did.

For a user who wants to listen to an internet radio station, I’ve gone with “Listener”, “Clothes shopper” or “Customer” for the second example and “Car Crime Investigator” for the third, but if we were working in each of these problem domains I’m sure we could do better!

Remember to be as specific as possible. The idea of stating the user is to help the team consider appropriate solutions. For example, consider the following two versions of a user story.

As a user, I want to be able to pinpoint a location, so that my delivery is accurate.”

As a missile launch specialist, I want to be able to pinpoint a location, so that my delivery is accurate.”

The description of the user is the only difference in the second story but it immediately makes you realise why accuracy might be more important for that type of user!

Before we move onto the next aspect of the composition of a user story, lets take a quick look at personas and how to handle requirements without an obvious end user.


A useful way of thinking about groups of users is to create user personas. The idea of personas is to encapsulate a whole class of users into a representative fictional character that can be used as a short-hand for all the users in that class.

Personas can be simple or detailed. Some organisations create detailed personas with fictional names, biographies and stock photos to bring the character to life.

Personas are great for developing empathy. As humans, we find it harder to inflict a bad system or process on a named individuals than we do on faceless “users”.

For example, on one project I was involved in, we invented the persona of the Grandma to personify our ageing customer base. “Would it work for our Grandma?” became a regular phrase that helped us to keep the needs of our older customers in mind.

If you are using personas, it is important to develop enough personas to cover your user base. If you don’t, you risk neglecting a class of your users and may miss specific user needs.

Back end stories

Sometimes you will be writing user stories for back end systems where the ultimate end user may not be apparent. For example, let’s imagine a bank that receives a daily file from another bank that provides a list of failed payments that must be reversed from customer accounts. In this example, it may be appropriate to personify our bank as being the end user, creating a story that starts, “As a bank, I want to process the daily payments failure file”. This is a common approach when defining back end systems, so don’t be afraid to go with it. User stories are all about communication, so don’t be afraid to move away from the normal template if it doesn’t make sense!

However you identify your users, when creating your user stories, you should put the end user at the heart of what you’re doing. Try to think about who they are and what they want in order to create a requirement that really works for them.

On a final note, if you’re struggling to define your end users, it’s possible you don’t know enough about them. In this case, I would strongly suggest not trying to write user stories; instead undertake some user research to try and understand your users and their needs in greater detail as this will help you to develop a better product. If you don’t know who your end users are, most of your work will be speculative and you will not know if you are building the right things!


The “I want” clause should be followed by what is actually needed. The description should be as unambiguous as possible but shouldn’t necessarily be prescriptive about the solution. Here are some examples

I want to be able to add a product to my cart”

I want to change my profile picture”

I want to sign up for email newsletters”

Sometimes the user may not actually want to do the thing we are describing, so in these cases, you may want to adjust the template slightly. For example, I want to pay my income tax may be stretching things a little too far!

In this case, it’s fine to say “I need to pay my income tax” or “I must pay my income tax”. Remember, the whole point of a user story is to encourage the right conversations with the team, it is unlikely that anyone will penalise you for not using “I want!”

In the examples above you will notice that the “I want” statements are all written as achievable goals that have a distinct end point. These are often known as “closed stories”; using closed stories helps to avoid open-ended and vague statements from creeping into your user stories.

For example, “I want to manage my account” is vague and can be updated into a number of closed stories that drive out better requirements such as;

“I want to update my password” and “I want to close my account”


The “So that” clause should be followed by a description of the user benefit or business benefit that is achieved when the action is carried out. This helps to convey why the functionality is useful and the value it delivers. Here are some examples

As a cook, I want to see the temperature of the oven, so that I can cook meat safely.”

As a call centre manager, I want to be warned when I have more than 10 calls in the queue, so that I can direct more colleagues to answer calls.”

As a pilot, I want to be able to lock the cabin door, so that intruders cannot access the flight deck.”

In each of these cases, the “So that” element of the user story helps us to understand why the user needs the functionality and can lead us to discover aspects of the requirement that might otherwise be missed.

In the case of the cook, the reason is to help them to cook meat safely and this may lead the team to think about whether the temperature is for the whole oven in order to avoid inconsistent cooking.

In the case of the call centre manager, the reason for the requirement is to allow the manager to react to an ever-changing situation; this may lead the team to consider how the warning can be delivered quickly and not be missed. Perhaps an audible alarm?

Finally, the pilot example may prompt the team to consider the security of the locking mechanism and how the pilot can know when it’s safe to unlock the door.

In each of these cases, providing “So that” information helps the team to develop appropriate solutions that work for the end user. It’s possible that the motivation for the requirement would emerge naturally through conversation, but having it written in the user story ensures that it is discussed.

There may be occasions where adding a “so that” clause may not actually add any value. A sign of this is when the “so that” clause simply leads you to restate the “what” in slightly different language.

For example, let’s take another example,
As a Fraud Prevention Officer, I want to be able to calculate the fraud rate, so that I understand the rate of fraud.”

In this case, it seems reasonable to drop the “so that” clause as it’s not really adding any value. As it stands, the redundant wording isn’t doing any harm, but it’s a bit pointless. If you are confident that you are wasting time following the usual template, you won’t be doing anything wrong if you drop the “so that”. As with all things, if you understand why each element is used, it should allow you to make sensible judgements about when to use them. Of course, if you’re uncertain, there’s little harm in including the additional text, so you can always err on the side of leaving it in!

It can be difficult to identify the real reasons why functionality is needed. You should try and avoid simply restating the functionality. For example;

“As a potential customer, I want to register for the film streaming service, so that I can sign up for the service.”

In this case, it’s unlikely that this is the potential customer’s real motivation, in fact it’s more likely that their actual motivation is to be able to watch some films! Try using a simple technique like “the five whys” (this is repeated use of the word why) to discover the real user motivation. A typical exchange may sound like this;

“So that I can sign up for the service.”


“So I am registered and can access the service”


So I can watch films

Perfect! That sounds like the real reason for wanting to sign up. It’s not always easy to identify the root of the users’ motivations. Once again, the best way is to have real conversations with your end users and really get to know them.

In this article we’ve looked at the most commonly used user story format and have looked at each of the elements in detail to understand why they’re used. Armed with this knowledge, you are equipped to decide how to use the template to communicate your end users’ needs and, importantly, can decide when slavishly following the template isn’t adding any real value.

Good luck!

If you enjoy reading stories like this and want to support me as a writer, consider signing up to become a Medium member. It’s $5 a month, giving you unlimited access to stories of Medium. If you sign up using my link, I’ll earn a small commission.




All aspects of organisational analysis: business analysis | enterprise architecture | quality

Recommended from Medium

Fitso: Empowering a socially-fit lifestyle

Mockup screens of the Fitso app

Questions that ruin usability tests

Guide to usability testing — don’t ask these questions

2 Lessons from a brand project fail

Why Zoom is ruining our Situational Awareness instincts

Best microcopy examples and some great insights

10 takeaways from an NDA Project

Takeaways — UX Case Study — NDA

UX is the most important SEO factor you are overlooking

A man points at the computer

5 UX Lessons from Nike GO FlyEase

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Chris Stevenson

Chris Stevenson

I’m interested in lots of things and write about them. History, nature, environment, business topics, experimental stories and anything else I fancy.

More from Medium

Agile Product Development

Agile Product Development

Scrum explained: The Product

Product Goal vs. Product Backlog

How to Distinguish Between a Product Designer vs. Product Manager