Great products are built by strong teams that can communicate openly with one another, but in product design, open communication is a relatively new idea. In fact, many of the methods we use in product design and development are younger than you — and user stories are among that group.

The brainchild of software developer Kent Beck, user stories were spawned in reaction to the Agile Manifesto, which radically altered the landscape of product development. Agile pushed for software development to be broken into smaller chunks, and user stories were those chunks. These new pieces were intended to spark conversations so that teams could communicate with one another more effectively regarding the product.

Before Agile, product development followed a process often referred to as Waterfall. With Waterfall, you work in large chunks are they were initially specified until you were finished. Worse, you work on those chunks without testing your work until the project was complete.

In Waterfall, your work was often dictated to you or “thrown over the wall,” and most designers did the same in return. Product managers threw designers the requirements, and designers threw a stack of PhotoShop comps to the engineers. At the end lived the quality assurance team who waited to see if a product eventually pops out.

If you’ve ever watched a TV cooking show like “MasterChef” or “Chopped,” this style of top-down direction and its assembly line process will sound familiar. Regardless of what you are provided, you’re expected to make something valuable out of the ingredients you’ve been given, and there is no further discussion on the matter. While this makes for entertaining television, it rarely produces a good product in any arena.

If you feel for those poor cooks, imagine spending weeks or months of your life on a project only to achieve similar results. There are thousands of projects that will never see the light of day because they were constructed under the wrong constraints.

However, things didn't change overnight.

The Agile Manifesto was released in 2001, but it took several years for it to gain ground in the industry, but over time it was widely adopted. That adoption reshaped how teams communicate and how products are built, and we now accept the push and pull of the iterative cycle that Agile created.

With Agile, moments of divergent and convergent activity became common as these different patterns of thought work with and against one another to produce the energy that pushes the process forward.

When we create user stories, we are actually doing both activities at the same time. Initially, we’re trying to narrow our focus in an attempt to imagine what our users want to accomplish. Our initial efforts will converge on a small set of stories that often results in the creation of the core of our product.

However, user stories always expand beyond the initial list. That’s because the stories that are generated on the first pass will have dependencies not initially considered. This leads divergent activity to fully establish the scope of the path ahead for your project.

The user personas and the scenarios you created in the previous chapter will make writing this initial set of user stories significantly easier.

The common formula for user stories follows a consistent pattern:

As a [user], I want to [task] so that I can [goal].

This might seem similar to persona goals, but those are explicitly written from the perspective of the user. Here, we have the advantage of knowing both what the user goals are and how the system might help them accomplish those goals.

Let’s build a few sample user stories to get a sense for how these are really constructed. In this example, we’ll use a simple persona (social media user), and the goal is to communicate with others.

content generator examples

Task	Goal
I want to post content	so I can share pictures of my family with friends.
I want to make a reply to comments	so I can carry on a conversation.
I want to edit posts	so I can correct mistakes.
I want to delete posts	so I can change my mind about the content I have posted.

Here our persona is clearly in a scenario that involves them posting content. This is one of many possible situations that the average user will face when using any social media site. This is not an exhaustive list, but it covers enough that you could begin envisioning how you might construct a test for product testing. Questions like _ “how would you post content to the site”_ stem directly from user stories like these.

Users + scenarios = plethora of user stories

As you discovered, while creating user personas, a user’s needs will change when the scenario changes. In the example below, we shift the user from creating content to consuming content, and you immediately have a different set of user stories emerge.

content consumer examples

Task	Goal
I want to comment	so I can participate in conversations someone else has started.
I want to like	so I can indicate approval without joining a conversation.
I want to block content	so I can remove unwanted items from my feed.

It is important to remember the secondary users and support staff that will keep your project up and running when creating your initial set of user stories. One of the most exciting things about writing user stories is how the act of writing them will force you to consider other types of users.

The specific user story drawing attention from our last set is _ “I want to block content.”_

What happens with that content that is blocked? Should it just be something that is removed from the feed or does the act of blocking the content raise concern about what the content is? If it raises concern, who investigates that content?

For practice, write a few user stories for the persona that would likely deal with blocked content. What role does that person play and what tools would they need. Log these into your program journal for later review.

Does the thing I need exist?

Creating user stories is like writing recipes for the future. At some point in the not too distant future, your team will attempt to build a solution, and you’re explaining to them what is required.

Much like a recipe, the level of detail you provide in your user stories should be both granular and actionable. If you have a user story that says ’I want to add an item to a list,’ you will also need a user story related to creating that list.

Not taking the extra step when creating user stories assumes that someone on your team will fill in the missing blank. Assumptions are the enemy of good user stories.

A time and place for priority

No two users stories are of equal weight, but that doesn’t mean that you need to decide regarding which of your stories requires attention first immediately.

When we assign importance to user stories, we begin to shape the initial versions of the project without fully understanding what will be required to have a testable MVP. This can lead to misguided assumptions about timing, which is a particular problem when you are trying to align your work with a live audience for user testing.

So for now, hold off of ranking these items against one another.