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 the marketing manager, I want to email my customers based on their defined interests so that I don’t send customers information unrelated to their interests.
- As a content manager, I want to review submitted articles from our readers before publishing so that I can maintain quality control of our content.
- As a marketing manager, I want to publish lead-generation forms to the site that pass data directly into Salesforce so that I don’t waste time manually importing data.
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:
- They put a human element to the software we’re building
- They are readable and efficient
- They encourage verbal communication, and
- They communicate the benefit of the user story, 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. Finally, Step 5 is breaking user stories down into tasks that can be completed either at the sprint level, or at the time you’re working on them.
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.
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 website, web app, or mobile app you’re going to build? Who is a stakeholder? Make sure they’re in the room. That can/should/might 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.
- A content manager, product owner, or other admin – if we’re talking about a website, who is managing the content? Who is fulfilling eCommerce orders? If we’re talking about web or mobile applications that have an admin side, who is handling that? Get these people in the room.
- IT staff – is there external or internal IT staff the digital product will affect? Get them in there!
- Managers/executives – are there managers or executives (marketing, operations, etc) who have goals and objectives tied to the execution of the site/app? Make sure they’re in the room for user story generation.
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!
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 you or they might not have otherwise thought about.
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.
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!