User stories, the stock and trade of JIRA and other software development environments for Agile methodologies should be a series of statements listing the different activities users want to accomplish…and why.
As a user type, I want to do something, so that I can meet this goal.
But, more often than not these are written as feature stories…
As a user, I want a table, to edit objects.
Each phrase of this story has issues.
- The specific user-type is not named
- The ask is for a specific feature
- The reason is vague
Let’s dig in and look at what should be going on…
State a specific user
Don’t assume that the audience of the user stories knows your product domain. Specifically state which users — first time, advanced, young, elderly, administrators, editors, processors, artists, … whatever is most important about the user that creates the need or desire to accomplish this activity.
An outcome of stating specific users is that it will become apparent that it would be good to write similar stories for different users — Ex. first time vs advanced. It’s likely that they will want the ability to accomplish the same activity but for different reasons or goals — and that needs to be captured.
As a first time user I want to understand what is possible to do so that I can figure out what I can do quickly.
As a first time user I want to understand what to do as quickly as possible to be productive.
As an intermittent user I don’t want to have to relearn the product each time I need to use it because that is frustrating.
As an advanced user I want the administration tools to be keyboard-driven so that I can work my fastest.
Be willing to state different users for the same activities and goals
You will often see user stories that just state that “As a user…” These blanket stories appear when writers feel that a need and goal is shared across all of their users.
There is value in writing stories about different users doing the same thing for the same goal.
At a minimum it leads to discussions to verify these different user types want the same things for the same goals.
As an admin, I need to see what reports have been run, so that I find one that I ran last week.
As an sales associate, I need to see what reports have been run, so that I can one that I ran last week.
An inference can be made that they have different unmet needs based on the context of their backgrounds. While it’s true that both roles need to find a report they ran last week. Its possible, and likely, that the reason they want to find it differs. In the difference of why they want to find it may be reasons that mean that they need different ways of finding and accessing them.
For instance the admin may be looking through a list of thousands and needs additional support to refine to the report they need. The sales associate may only have tens of reports and wants to find a report based on content.
As an admin, I need to see what reports have been run, so that I find one that I ran last week out of the thousands that ran.
As an sales associate, I need to see what reports have been run, so that I can one that I ran last week listing my products.
Putting in the effort to tease out the differences will help create a product that better suits each of its users.
State what activity the user needs or wants to accomplish
Don’t state that users want a feature because that feature may not be the best solution. Tell the team what activity the user needs to accomplish and let them figure out what the appropriate features are.
Users rarely ask for specific features, but the writers of stories often write the thing they know or that they think will be easy to implement. Even when users ask for specific features it is often because that is what they have used, not what would solve the problem best. Feature-focused stories will not lead to best of class or innovative experiences since they encapsulate existing mechanisms for activities.
So instead of:
As an Admin, I want a table to manage users, so that I can add, delete and edit them.
Digging into what an Admin cares about when managing users might result in:
As an Admin, I want user management that makes roles apparent, so that I don’t create any users with improper credentials.
The experience may still contain a table but might be geared more to making sure their credentials meet company guidelines and in addition to CRUD (Create, Read, Update, Delete) activities additional activities may be added to debug and understand credentials.
Needs vs Wants
The following is a standard format for a user story with one word changed…
While indicating the depth of the users interest in a activity the verbs “want” and “need” can also indicate a product’s focus. The word “want” is a desire-focused verb, often used either for activities that consumers would like to accomplish while “need” often denotes activities that enterprise users are required to do.
Consumers can need things and enterprise users can desire things but in the different contexts these verbs carry different weight. Consumer’s needs are still usually internal desires, while enterprise needs are usually requirements from management to work a certain way. Enterprise desires are nice to fulfill, but are super-ceded by requirements. Enterprise users like their desires being met but the product will not be bought by them. Leadership, who pays for the product, cares whether users complete activities correctly. Consumer desires drive stickyness and so while the product needs to meet their needs, meeting their desires is more likely to hold them.
It is important in a story to provide the correct level of user interest as it will be needed later to help determine priority.
Different activities for the same user and goal
As a Admin, I need to CRUD (Create/Read/Update/Delete) the table’s objects, so that I can manage objects.
As a Admin, I need to sort the table, so that I can manage objects.
The “so that…” phrase of these stories is weak — knowing how and why the user needs to manage the objects would help prioritize how to disclose affordances to the CRUD and sorting, but this lack of depth of customer needs is common.
State a reason that helps prioritize this activity over others.Don’t restate the ask or state that the activity needs to be accomplished.
Some user story references call the last phrase the reason. The problem is that reasons can easily be vague. “Edit an object”, is the reason but will not help the team understand how or why this activity relates to others the user wants or needs in the experience.
The “so that” phrase provides design direction that indicates what about the activity is important. Is it important that this activity be completed correctly or efficiently, helps user understand how things are related, or is fun, engaging, or educational?
The “so that” phrase can also tie a series of user stories together to help the team understand how much effort should be put into this activity by itself and related to others.
Different goals for the same users and activities
Again, it’s important to write specific stories, not broad ones that are expected to be a catch alls for a feature direction. If the user will want to do the same activity but for different reasons the different reasons will articulate additional features they need to accomplish their goals.
As a millennial, I want to share photos, so I can show my friends the cool places I have been.
As a millennial, I want to share photos, so I can keep in touch with my parents.
As a user, I would like to be able to sort the table, so that I can find objects by priority.
As a user, I would like to be able to sort the table, so that I can see how many objects are above $500.
Leveling up User Stories
The following are a series of “user stories” from a site that comes up high on internet searches for “user stories.”
As a user, I can backup my entire hard drive.
As a power user, I can specify files or folders to backup based on file size, date created and date modified.
On the site these are considered Epic level stories — high level, to be broken down into sprintable stories.
These stories don’t have reason statements and they are feature-focused. There almost isn’t a reason for them to be in story format.
To create innovative products Epic level stories are a good place to make sure the reasons are spelled out. A well stated reason can help the team shape the feature and its relationship to other stories.
As a user, I need to be able to backup my entire hard drive, so that in situations where I didn’t predict what files I might need later they are still available.
This lets the team know why this important and could lead to features where the the backup can be made to watch for important files it should predictively back up more often.
As a user, I need to be able to backup my entire hard drive, so that I can recover from total drive failure quickly.
This lets team know that they should consider this as part of a full drive recovery experience. Understanding how this activity fits into the whole will help prioritize related activities.
Around the activity-level stories is the cloud of context where the team has agreed on directions or principles that turn into implicit assumptions. An example would be the difference between an enterprise and consumer.
This story reads differently between these two users types.
As a user, I need to add users to a folder quickly, so that I can finish the transaction while on the phone.
Strategic stories can help solidify the context. If we first present one of these stories then further stories will be more grounded.
As an enterprise user, I want to complete transactions quickly, because I need to close tickets.
As an consumer, I want to complete the transaction quickly, so that my loan gets processed.
Writing a few of these extra stories can help the team keep in sync as well as remove ambiguity about direction.
Emphasize different kinds of emphasis
Make sure the team knows how and why activities and goals are important. Emphasize the activities and goals with appropriate adverbs.
As a long time Facebook user, I want to easily send messages to specific groups of people, so that I can have conversations that I don’t want to be Public.
As a long time Facebook user, I want to send messages to specific groups of people, so that I can easily have conversations that I don’t want to be Public.
The right mixture of stories with specific phrasing will generate a user-focused and innovative product.
Also see the User Story Prime Medium article for additional methods for generating user stories that drive innovation.