Understanding and Creating User Stories

When we’re getting started building a digital product, we need to understand why we’re building it (in the form of a digital project brief) and who we’re building it for (which can be captured in user personas). But then we get to the question: what exactly needs to be built?

That’s where user stories come in. User stories are a way of communicating project requirements from the perspective of the end user. Here are some quick examples of what user stories can look like:

• As a prospective buyer, I want to reset my account password if I’ve forgotten it so that I can access my account.
• As a history buff, I want to read personal stories from historical events so that I can get a better feeling of what it was like to be there.
• As a buyer, I want to see the full name of the individual I am purchasing from so that I can avoid falling for scams.
• As a driver, I want a reminder to complete my routine maintenance so that my semi-truck is operating safely on the road.

User stories are usually written on cards following this format:

As a <user persona> I want <functionality> so that <benefit / rationale>.

They are absolutely integral to the success of a digital project. They’re captured in a specific method, which we’ll outline, and then used for everything from project estimation through to prototyping, design and development, and testing.

Let’s talk more about why user stories are so important, and then we’ll dive into how to actually create them.

Why User Stories?

From a high level, user stories (compared to extraordinarily detailed written requirements, ISO 29148-2011-style) have a few key benefits:

1. They put a human element to the software we’re building
2. They are readable and efficient
3. They encourage verbal communication, and
4. They communicate the benefits to the user, which is integral for prioritization purposes.

However, discovering and writing the user stories is only step 1. Step 2 is prioritizing them. Step 3 is discussing them to ensure comprehensive understanding. Step 4 is outlining the acceptance criteria for each story so you can test them to ensure they’ve been properly met.

After those steps, user stories are continually referred to throughout the information architecture and prototyping stages of a digital project, and in quality assurance / user acceptance testing phases as well, to ensure the holistic digital product is doing what it needs to do. User stories might also get added throughout the project as you discover more information, test the prototype or product with your users or just have those “wouldn’t it be cool if…” moments.

Basically, you can’t execute on a project without knowing the details around what you’re supposed to be building and why, and user stories are the best way to accomplish that.

Using a Workshop to Capture User Stories

Capturing user stories isn’t that difficult. There’s no singular “right” way to do it – so instead, I’ll just tell you how we do it at Paper Leaf.

All of our projects start with a kickoff. We cover a lot of ground in this kickoff – from outlining initial user personas to outlining how we work using Kanban and much more. They take at least half a day, and often a full day. However, arguably the most important portion of the kickoff – assuming user stories or requirements haven’t yet been captured properly or captured at all – is around user story generation and prioritization.

The first key in capturing effective user stories is to ensure the right people are in the room. Who will be affected by the web app or mobile app you’re going to build? Who is a stakeholder? Make sure they’re in the room. That should include:

• An end-user representative – Someone who can speak to the end-user’s goals, objectives, and context. Ideally it’s an actual user or group of actual users. However, as discussed in the article about user personas, sometimes that’s not always feasible.
• Individuals who interact with your end user on a regular basis — If you have a call centre or customer service team, these are great people to bring to this meeting. They will have first hand knowledge of the experiences your user is having.
• A content manager, product owner, or other admin – If your web or mobile applications are going to have admin functions, who is handling that? Is there a current application or process being replaced? If so, who does the most work within that tool or process?
• IT staff – Is there external or internal IT staff the digital product will affect?
• Managers/executives – Are there managers or executives (marketing, operations, etc.) who have goals and objectives tied to the execution of the app?
• Decision makers — Who gets the final say about the product?

Say it with me: “Make sure they’re in the room!”

Once the right people are in the room, give everyone a Sharpie or pen and a stack of flashcards. Feel free to download and use our free user story flashcard template and print some off yourself. That way, you can be sure you’re getting the right information.

Once everyone has a pen and a stack of blank flashcards, write down the format for user stories up on the whiteboard:

As a <user persona> I want <functionality> so that <benefit / rationale>.

Then, instruct everyone to begin writing user stories down on their cards following the format above. When someone completes a user story, they are to hold the card up to the group and read it out loud, then throw the card in the middle of the table. Just keep doing that over and over, and soon you’ll have a big stack of user stories!

Running this workshop remotely

Sometimes it’s not possible to get all the people you want to participate in the workshop in one location. This workshop can easily be done remotely. Replace flashcards with a shared Google sheet (or a similar tool where multiple people can write and contribute simultaneously) and a virtual meeting room on Zoom, Google Meet, or one of the many other video conferencing tools.

User Story Pro-Tips

The purpose here is not about feasibility or prioritization. It’s about generating a huge, exhaustive pile of user stories. They’ll be evaluated for feasibility and prioritization later, so tell people not to worry about that.

You don’t need to go around the room in order. Free for all!

Anyone can write a story for any type of user. For example, IT staff can write a story for an end-user group.

If you’re unclear what someone’s user story means when they read it out loud, ask. This method allows for communication, so take advantage.

That said, now isn’t the time to unpack acceptance criteria. That comes later – so don’t talk for 10 minutes about every story or else you’ll probably die in that board room.

Encourage people to write and share their stories one at a time, as opposed to sitting there writing a million user stories at once. In our experience, we’ve found that verbalizing user stories out loud is a great brainstorming tactic – it’ll spur others around the room to capture a user story they might not have otherwise thought about.

If the group gets stuck, you can prompt them. Think about the specific reasons you want to build a digital product and ask the group questions about that. For example, if you are building a mobile app that requires users to sign up for an account, what do you need to do to sign up? Another example would be if your app lets people complete an assessment – what does that assessment entail?

It’s handy, if not required, to have your user personas in front of people. Print them off, have them up on a wall, have them on a slide. Regardless, the user stories are literally stories about those users – being able to refer back to the user personas makes writing user stories way easier and more efficient.

You don’t have to get everything captured and figured out in one meeting. You won’t be able to think of every possible user story in one session. As you work through workflows, prototyping, user testing and product development, your team will find additional user stories that you hadn’t thought of before. Consider the place where you keep your user stories a living document. This will allow you to plan out releases for your product that extend well past your initial launch.

The length of this exercise is totally variable depending on the size of the project, the number and type of people in the room, and many more variables that expose themselves while deconstructing a new project. Some of our experiences with these workshops have been as short as 30 minutes and some have been as long as a couple of hours. Regardless, your group will either naturally start to slow down, or you’ll hit the time limit for your meeting agenda. If the latter happens, don’t worry – additional user stories can and should be continually discovered throughout the life of the project. This isn’t your only opportunity to capture them.

When you’re done capturing all the user stories, the next step is part 2: prioritizing them. Click through and read the next article in the series, and learn how to prioritize user stories!