User Story Prime

Lightly edited from original published on LinkedIn May 17th 2016.

A user story is an artifact for describing what users want in terms development teams can use to create experiences that users find useful, usable and possibly delightful.

User stories take the form of — As a <user type>, I want a <capability>, so that <I can accomplish some goal>.

What makes a good User Story? Opinions vary. Let’s discuss…

Better stories: User stories you can be sure reflect what users want.

I was working on a social media platform for enterprises and we started work on a new feature. When we sat down to start writing user stories they were immediately cast as — As a user; I want SOME aspect of THE NEW FEATURE (couched in terms of our current product). It would be the same as saying — As a Facebook user; I want to be able to create groups so that I can organize friends.

As a designer, I was uncomfortable with this direction. User’s rarely want anything so specific as feature. User’s want capabilities. Couching the stories in terms of specific features inferred that we were meeting the users requirements when in fact we focusing on how we could address their needs based on our existing model.

Some users in studies may have mentioned groups but most likely they were just stating a preference for organizing friends. Likely they just said that they were getting overloaded by the number of friends they had. In the end Groups is Facebook’s choice of how to enable that organization. Writing “groups is what users want” in this case would be disingenuous.

After working through the process with a great mentor and creating approximately 100 user stories these are a few things I now try to keep in mind.

INVEST-able stories: Be careful on focusing on them too soon.

In an attempt to be agile teams jump to get user stories that meet the INVEST (Independent, Negotiable, Value, Estimate, Small, Testable) standard. The INVEST standard is a great end point but it is one that should be approached carefully.

The stories which really drive user-centric innovation meet none of the INVEST criteria. While we can’t directly build features or products that meet these goals the most basic user stories come from Maslow’s pyramid.

As a user, I want sustenance.
As a user, I want shelter.
As a user, I want to belong.
As a user, I want respect.
As a user, I want to have fun.

A good exercise is to use these stories as a lens to look at business drivers and technology possibilities to see how they will impact the user’s life. It is useful to see if the implementable user stories track back to these goals or are meeting an artificial goal.

For example if we were a company with a new technical ability to provide analytics about users musical tastes these stories could be expanded to reflect what the user wants.

As a user, I want to understand my peers musical tastes so that I can (belong) (have fun) (gain respect).

Each of these endings provides a different direction to take that technical possibility.

Misattributed goals: That user doesn’t have that need.

Artificial goals come about when we cast one user’s requirements as another user’s desire. For instance if we write a user story — As a end user, I want to login so that my information is secure — then we have attributed the requirement to the wrong user. The user wants security but does not care about how it is implemented. The user wants security with the least amount of friction. If instead we say, “As an admin, I want users to be required to login to keep the site secure.” — we are casting this requirement in the correct user’s voice. The admin wants a particular implementation, probably because it meets some system goal.

There should not be any user stories that state that the user wants to take an action that in any way does not benefit them. Stories about security, data about themselves, data that helps someone else make decisions or categorize data are someone else’s story — often the companies or communities.

When considering computer use, User Story Prime, the most realistic user story is…

This story helps us focus on the fact that, in reality, the user doesn’t want any intermediary between what they want and reality. Experiences that facilitate simple, efficient interactions are what they want.

Focusing… on the wrong things — on existing models.

Another area that can cause issue when writing user stories is for them to focus on interactions instead of desires. As we stated early it is disingenuous to say that the end user ever wants to use our software.

Yammer, Facebook and other social media users want to communicate. They want to use these platforms because of their reach not because of a particular feature. In fact, for any feature on these platforms most users would probably give you a number of reasons why it does not meet their needs.

Additionally, it is disingenuous to say that the user wants to use a particular affordance — i.e. As a user, I want to use a drop down to select X. At best the user wants to select X. In truth they would prefer to not even have to select X. They would prefer the system knew they wanted whatever selecting X meant and did it for them.

User stories are contrived when they are articulated to state the user wants to use an aspect of an existing system — The user uses feature Y to do something. While a user in a study may have said they want to use a particular feature of the existing system to accomplish a goal it should be taken as a broader hint to look at the system and see if the model is broken. In this way we should be following (not) Henry Ford’s quote about if he had asked what his customers wanted.

It is incidental that the user wants anything from software. They want an experience and the product may be a conduit for the experience. There are often multiple conduits and like electricity the conduit of least resistance is the one they will prefer.

The user story that has the most likelihood of creating a product the user will not only use but promote is — As a user, I want to be delighted. Trying to create features or products that meet this story helps us focus on how the product is perceived instead of just the tasks it accomplishes.

Getting attribution right: Different users. Different points of view.

There may be many user types of the product. Each has their wants. Sometimes they are conflicting.

For consumer software there is generally two users; the end user and the product creator. End user stories should revolve around Maslow’s needs. Product creator stories revolve around business models and technical possibilities.

For enterprise software there is the user, the organization and the product creator. There is a tension in the stories between the user and organization. Enterprise software generally prioritized the organization’s story over the users.

For instance a common conflict is:
As a user, I want to communicate so I can be efficient. 
As an organization, I want secure communications so that data cannot used inappropriately.

We need to be cognizant of the conflicts and explicit state in user stories which way they are resolved.

  • As an employee, I want to communicate with as many people who can help me be successful as possible.
  • As an organization, I want my employees to communicate in ways that increase profitability.
  • As an organization, I want my employees to communicate in ways that minimize risk.
  • As <company X>, I want to provide a service which maximizes profit.

Innovation comes finding the company’s user story that blends technology possibility, business requirements and user’s needs. The stories that create great products are the company’s stories that balance the users wants vs companies abilities.

As a user, I <CompanyX>, want to provide services users or organizations will pay for in a fashion which will make us more profitable.

Acceptance Criteria: Accepting our ability to meet different levels of Done.

By ranking implementation direction in the Acceptance Criteria of strategic user stories we can set expectations about how a product can be staged for INVEST-grade ones.

Ranking can be MVP (minimum viable product), to Target to Complete. The last ranking can be different depending on what your focus is. Consumer products are geared for delightfulness, so instead of saying “Complete” you might say “Delightful” as a way to emphasize that the goal, though it may take a lot of effort, is for the product to delight the user.

As a user, I want to understand my peers musical tastes so that I can gain respect.

Acceptance Criteria:

  • MVP — List of songs my friends are listening to.
  • Target — Interactive list with tools to add and merge their lists with mine.
  • Complete — Interactive list with real-time controls to adjust how much of friends music to play.
  • Delightful — Interactive graphic where I can indicate how our likes relate.

Writers Bias: Keeping our role’s biases out of the user’s heads.

Each of the participants of the process has their own pressures and desires related to their roles in the process. As well as understanding how to phrase what we think the user wants we need to understand how not to introduce the biases of what we would like into the user stories. To whit:

  • As a designer, I should not skew stories towards designs I like or away from those I dislike.
  • As a product manager, I should not skew stories towards existing solutions.
  • As a developer, I should not skew stories towards technical solutions that I like or away from those I dislike.

Keeping these aspects of user story creation in mind helps us create products that really do meet what the user wants.

Show your support

Clapping shows how much you appreciated Karl Mochel’s story.