19 Tips - Writing Effective User Stories

Thinking out-of-box while writing user stories.

Aug 06, 2023

👋 Hello,

Welcome to the ⭐️ free monthly edition ⭐️ of my weekly newsletter, the “Winning Strategy.” Every week, I answer one reader question about agile, product, roles, skills, job interviews, frameworks, working with humans, and anything else that you need answered about your career growth. You can send me your questions here.

If you are new to Winning Strategy, here’s what you have missed:

Note: If you enjoy reading this post, would you mind showing your support by clicking the little gray heart below the title above? It would really mean a lot and help spread the word about this growing newsletter. 😍

On to this week’s question!

Q: User stories are getting stale. Can you provide some practical tips from your experience?

Absolutely!

One useful habit that I developed over the years (besides reading) is to document such events that gave me a fresh perspective to look at everyday mundane things like writing and helping teams write User Stories.

Here are 19 tips for writing effective user stories.

#1 Persona-Driven Stories

Persona-driven stories are an essential aspect of Agile development. These stories put a "face" to the user base, helping to empathize with and understand the user's motivations, needs, and pain points.

Truth - “Most teams skip building user personas while writing user stories.”

During my tech days at IBM, I was part of a team that was creating a customer support chatbot powered by preliminary AI technology. This chatbot was aimed at helping users troubleshoot common issues and answer their queries without having to wait for a human support agent.

We were not pros at user story writing, but we had a habit of approaching every problem starting with a user persona. For the chatbot, we created a user persona called “Sam” as follows:

"Sam is a busy small business owner who relies on IBM's products for various aspects of his operations. Sam is frequently on the move, making it difficult for him to find time to get on a call or wait for a support agent to address his queries.”

Instead of writing a generic user story such as:

"As a user, I want a chatbot that can quickly answer my questions so I don't have to wait for a human agent,"

we used Sam's persona to craft a more targeted user story:

"As Sam, a busy small business owner, I need an AI-powered chatbot that can promptly answer my questions and troubleshoot issues, so I can resolve problems quickly and focus on running my business."

This story provided a richer context for the team. It gave them a glimpse into Sam's world – his

motivations,
needs, and
constraints.

The team could now imagine Sam trying to juggle multiple things and how an efficient chatbot could significantly help him.

Crafting persona-driven stories is like having a direct conversation with your users. It helps the team step into the users' shoes, ensuring that the solution they develop genuinely addresses their needs.

Developing personas before guiding the team in writing user stories was the most valuable habit I adopted during my time at IBM.

#2 Illustrate with storytelling

Imagine this:

You're working on an app that helps writers organize their work.

After doing some user research, your team learns that writers, especially freelancers, often juggle multiple assignments from different clients simultaneously.

They struggle to keep track of where each piece is in the process, which can lead to missed deadlines and frustrated clients. This research reveals an opportunity for a new feature in your app that could help writers manage their assignments more effectively.

Now, instead of simply saying

"A user can track their writing assignments",

you can craft a more detailed user story that humanizes the problem and paints a more vivid picture.

Let’s again start with creating a user persona, “Sarah.”

Sarah is a 32-year-old freelance writer.
She is always juggling multiple writing assignments.
It's crucial for her to stay organized to meet her deadlines and keep her clients happy.
It's tough for her to remember the details and due dates for all her projects.

Let’s illustrate this with storytelling.

"Sarah, a busy freelance writer, can create, update, and view a list of her ongoing assignments in our app, which includes details such as the client's name, project title, word count, and due date. This way, she can keep track of all her tasks and deadlines in one place, making sure she never misses a due date and can easily update her clients on the progress."

Note: Not quite an “As a user…” type user story, is it? It’s an epic that needs to be decomposed into smaller user stories. Format isn’t important. What’s important is that your team understands, “What’s the problem”

In this example, we didn't just state the functionality; we created a narrative around Sarah’s need.

It's easier to imagine the practical application of the feature when it's framed this way.

Keep in mind: Although this level of detail is usually helpful, it's not always necessary for every user story. The goal is to provide enough context and detail for the team to understand the user's needs and design an effective solution.

Always consider the complexity of the feature and the familiarity of the team with the user's needs when deciding how much detail to include in your user stories.

#3 Backward Stories

Sometimes it's beneficial to flip the traditional user story format to start with the outcome first and then work backward to the user's actions. This can help the team focus on the ultimate goal and design more effective solutions.

Imagine this:

You're working on a News Aggregation app.

Your team receives feedback from users that they're having difficulty locating articles they've read previously. They want to revisit certain articles for reference, but finding them again is proving to be a tedious task.

This right here is an opportunity to improve user experience.

Normally, you might write a story that says:

"As a user, I want to save articles so that I can easily find and refer to them later."

However, if we flip this to start with the desired outcome first, we get a fresh perspective on the user's needs.

Persona! Meet Paul.

Paul is a 27-year-old journalist who uses the news app to keep up with current events and get story ideas. He often finds articles that he'd like to reference in his own stories or read again later. However, he finds it challenging to locate these articles when he needs them.

A Backward Story would look something like this:

"In order to easily find and refer to interesting articles later, Paul wants a way to save articles within the app."

This phrasing emphasizes the desired outcome (easy access to saved articles) and prompts the team to think about the best way to achieve this goal.

It’s almost like writing the “so that” part first in a user story.

#4 Use the User’s Language

Imagine this:

You're building an app for hikers that helps them find, navigate, and rate trails.

After doing some user research, you've noticed that hikers use specific terms in their community. They talk about

"bagging peaks,"
"tackling trails," or
"scrambling,"

which might be unfamiliar to those outside the hiking community.

To make sure your user stories are as clear and effective as possible, you incorporate this language into them.

Persona: Emily.

Emily is an experienced hiker who loves to tackle challenging trails and bag new peaks on weekends. (notice the use of “bag new trails”).

A traditional user story might look like this:

"As a user, I want to record my completed trails so that I can keep track of my achievements."

While this gets the point across, it could be made more effective and engaging by using the hiker's language.

"Emily, an enthusiastic hiker, wants to log each peak she bags using our app, allowing her to celebrate her achievements and share her experiences with the hiking community."

Note: It’s an Epic. I know.

Here, we've used the term "bagging peaks," which is familiar and resonates with hikers like Emily.

This provides a clearer picture of the user's needs to the development team and can contribute to the creation of an app that hikers will find useful and relatable.

#5 The Goldilocks Principle

This is all about achieving the right level of detail in user stories.

You want to provide enough information for the team to understand the user's needs and the value of the story, but not so much that it becomes overwhelming or restricts creative problem-solving.

During my days at Amazon, I was part of a team that was working on a feature for Amazon's e-reader, Kindle, specifically focusing on improving the dictionary look-up experience for users.

Persona: Alex

"Alex" is a 45-year-old bookworm who loves using his Kindle to read a variety of genres. One day, he dives into a historical novel rich in old English words, which often sends him to the built-in dictionary. He finds the process of returning to his reading spot after looking up a word cumbersome, disrupting his reading flow.

A vague user story would look something like this,

"As a user, I want an improved dictionary feature."

This doesn't provide enough information for the development team to understand what needs improvement and why.

A too-detailed user story would look something like this,

"As a user, when I long-press a word, a pop-up window with the dictionary definition, synonyms, translations, and etymology should appear, and when I click outside the window, it should disappear, bringing me back to my original reading spot."

This leaves no room for the development team to come up with innovative solutions and might restrict their creativity.

Applying the Goldilocks Principle, a 'just right' user story could be,

"Alex, an avid Kindle reader, wants an easier way to look up unfamiliar words and return to his reading spot, so he can maintain his reading flow and enrich his understanding of the novel."

This story provides enough detail about the problem and its impact on the user but leaves room for the development team to explore solutions.

#6 Focus on Outcomes, Not Outputs

When writing user stories, it's easy to get caught up in specifying the exact features or "outputs" that you “think” the user needs

However, it's often more effective to focus on the desired outcomes – what the user wants to achieve – and leave the specifics of how to achieve that up to the development team.

Note: This is also what empowering your team looks like.

During my days at RBC, I was working with a team tasked with improving the user experience of the bank's mobile app.

Through user feedback and research, we learned that many users were frustrated with the process of depositing checks through the app.

Persona: Mike

"Mike", is a 50-year-old small business owner who uses the RBC mobile app for his banking needs. He's often on the go, meeting with clients and suppliers, and he relies on the mobile app to deposit checks quickly and efficiently. However, he finds the current check depositing process frustrating and time-consuming.

An output-focused user story might look like this,

"As a user, I want the app to have an auto-detect feature that automatically captures the image of the check when I'm depositing it."

This story specifies a particular feature or output – the auto-detect feature.

But what if the auto-detect feature isn't the best solution?

What if there's a more innovative, effective way to streamline the check depositing process?

That's where outcome-focused user stories come in. Here's an example,

"Mike, a busy small business owner, needs a quick and efficient way to deposit checks through the RBC mobile app, so he can spend less time on banking and more time running his business."

This story doesn't dictate a specific solution.

Instead, it clearly states the user's need (quick and efficient check depositing) and the desired outcome (spending less time on banking and more time running his business).

This gives the development team the freedom to brainstorm and innovate, which can ultimately lead to more effective, user-centred solutions.

#7 Distinguish Between User Roles

Understanding and distinguishing between user roles is crucial when writing user stories. Different roles will have different needs, and distinguishing between them can help you create more targeted and effective user stories.

At Twitter, my team was working on a feature to improve the platform's ability to manage and respond to notifications.

At that time, 2 primary types of users interacted with Twitter's notifications.:

regular users and
verified users, such as celebrities or influencers, who receive a significantly larger volume of notifications.

Persona: Rachel

“Rachel" is a verified user who is a popular influencer. Rachel often finds it challenging to manage the flood of notifications she receives, making it difficult for her to engage with her fans effectively.

A generic user story might look like this,

"As a user, I want to be able to filter my notifications, so I can respond to important ones quickly."

While this story is applicable to all users, it doesn't specifically address the unique challenges that Rachel, as a verified user, faces.

A more specific user story would look something like this,

"As a verified user, Rachel wants advanced filtering options for her Twitter notifications, such as segregating fan responses, personal mentions, and business inquiries. This will allow her to manage the large volume of notifications more efficiently and engage with her fans and contacts more effectively."

By distinguishing between regular users and verified users, this user story presents a more specific problem and allows for the creation of a more tailored solution. It provides clearer direction for the development team.

#8 Quantitative Outcomes

Quantitative outcomes in user stories help to establish clear and measurable goals that give the team a definitive target to aim for.

By stating precisely what success looks like in numerical terms, teams can assess the story's impact more accurately and continually improve the product based on real data.

Twitter’s user engagement team was working on improving user engagement for the "Explore" tab, which curated trending topics and personalized content for users.

Persona: Nina

Nina is an active Twitter user who loves to stay up-to-date with trending topics and discussions. However, she often finds herself missing out on trending topics that align with her interests.

A typical user story would look like this,

"As Nina, an active Twitter user, I want the 'Explore' tab to better curate trending topics based on my interests, so I can easily find discussions that matter to me."

While this is a solid story, it could be more effective by defining success in a quantifiable way.

You can add a measurable outcome like so:

"Our goal is to increase Nina's engagement with the 'Explore' tab by 20% over the next quarter."

Now it’s clearer what the team is aiming for.

Instead of a vague "improve engagement," they have a specific, measurable target of a 20% increase. This enables the team to track the impact of their work more accurately and adapt their approach based on the actual data.

After implementing the changes, the team can analyze Nina's (and users like her) engagement levels with the 'Explore' tab. Did it increase by 20%? If not, why? What can the team learn from this?

#9 The ‘Why’ Behind 'Why'

The 'Why' behind 'Why' is all about digging deeper into the user's needs and understanding the underlying motivations behind their actions.

This approach guarantees that the team is not just addressing the superficial needs of the users but also their deeper, often unspoken needs and desires.

At Amazon, we were trying to enhance the personalization of the product recommendations on Amazon's homepage.

Our user Person was Ella as below.

"Ella is an avid reader who frequently purchases books from Amazon. Ella appreciates the personalized recommendations but feels that they could better reflect her varied reading interests, which span across different genres and authors.

A basic user story would have been,

"As Ella, an avid reader, I want more varied book recommendations so that I can discover new authors and genres."

While this captures Ella's need on the surface, we can dig a little deeper.

Why does Ella want more varied recommendations?
What is her underlying motivation?
Perhaps Ella enjoys the thrill of discovering new authors, or she loves learning about different topics and perspectives through diverse genres.

A revised user story would look something like this:

"As Ella, an avid reader and lifelong learner, I want more varied book recommendations to feed my curiosity and broaden my horizons."

This version of the user story provides a richer and more comprehensive view of Ella's needs.

It's not just about getting different book recommendations; it's about satisfying her intellectual curiosity and her love of learning.

This deeper understanding can also spark new ideas for the team. For example, besides diversifying recommendations, could they also provide a brief overview of new genres or authors? Could they curate "learning paths" with books across different topics?

I would love that option.

#10 Non-User Stories

In Agile, we often focus on user stories, which is essential for creating user-centric products. However, it's also important to consider non-user stories.

Also called “System Stories,” these are requirements that may not directly involve a user's interaction but are crucial to the system's functionality, security, or performance.

My team at RBC was working on developing a new online banking portal. The focus was primarily on features that direct users interacted with, such as

transferring money,
paying bills, or
checking account balances.

Persona: Diana is a frequent user of online banking who appreciates efficiency and security.

One user story might be,

"As Diana, I want to easily transfer money to my other accounts so that I can manage my finances quickly."

This user story captures a significant aspect of the user's interaction with the system, but what about requirements that are crucial but not directly user-facing?

For example, the online banking system needs to handle a huge amount of concurrent transactions securely. It's not directly about Diana’s experience, but it's absolutely crucial for the system's functionality and integrity.

A non-user story might be,

"As a system, I need to handle thousands of concurrent transactions so that the online banking service can operate reliably and securely."

Non-user stories like this one help ensure that vital backend requirements aren't overlooked in the rush to deliver user-facing features.

They're a crucial reminder that while user stories drive the product's visible aspects, non-user stories ensure the underlying system is robust, secure, and efficient.

#11 Edge Cases

Edge cases refer to scenarios that are not part of the 'normal' user experience but could occur and need to be addressed to prevent system failure or user frustration.

They're often overlooked because they aren't part of the regular user flow, but they are critical to ensuring a comprehensive and robust product.

Imagine you’re part of a team working on a data analytics platform.

Persona: "Alex," a data scientist who uses the platform to analyze large datasets.

A typical user story might be:

"As Alex, I want to be able to upload my datasets in various formats so I can analyze them on the platform."

This user story covers the standard scenario of Alex uploading his datasets.

However, what about the edge cases?

For example, what if Alex attempts to upload an unusually large dataset or a file that's corrupted?

It's essential to consider these scenarios in your user stories to ensure a smooth user experience, even in exceptional circumstances.

You could write an edge-case story like,

"As Alex, if I attempt to upload an unusually large or corrupted dataset, the system should notify me of the issue and not crash or lose my other data."

Using edge cases in your user stories, you can make sure the system can handle exceptional situations gracefully.

It helps the development team anticipate potential issues and build a solution that is robust, reliable, and user-friendly under various circumstances.

#12 Experiment with Formats

While the standard

"As a [type of user], I want [some action], so that [some outcome]"

format is quite effective for writing user stories, it's not the only way to express a user's needs and desires.

Experimenting with different formats can help teams think outside the box and gain new insights about their users and the product.

Imagine you’re part of the team “Kindle” at Amazon that was working on developing a new feature which lets users annotate and highlight their ebooks.

Persona: "Riley," an avid Kindle user who loves to take notes while reading.

A typical user story might be,

"As Riley, I want to be able to highlight text and make notes in my ebooks, so that I can review my thoughts later."

While this story is effective, we can experiment with different formats to provoke new thoughts and discussions.

For example, we could try a question format, “How might we…”

"How might we help Riley capture her thoughts while reading without breaking her immersion in the book?"

This format encourages the team to think about the problem from different angles.

Rather than immediately jumping to a solution (highlighting and notes), the team can brainstorm various ways to fulfill Riley's underlying need “to capture her thoughts without breaking her immersion.”

Perhaps they could explore

voice-to-text options or
automatic bookmarking of sections where Riley lingers for a long time.

#13 Usage Scenarios

Usage scenarios allow us to depict real-life situations in which a user would interact with the product.

They help the team visualize how the user would navigate through the product, thus making the user stories more relatable and easier to understand.

Imagine you’re part of a team at Twitter that was working on a new feature to enhance the ease of thread creation for users.

Persona: "Sam," a journalist who regularly uses Twitter to share news stories and his analysis.

A typical user story could be,

"As Sam, I want an easy way to create and publish threads so that I can share complex news stories efficiently."

While this story provides a good start, we can use a usage scenario to paint a clearer picture of Sam's needs and how he would use the feature.

Let's describe a specific situation in which Sam would use the new feature.

"On a Wednesday morning, Sam is working on a breaking news story about a recent political event. He has analyzed the situation and wants to share his insights with his Twitter followers. He decides to create a thread to detail the complex events.
As he starts composing the thread, he appreciates the draft feature that allows him to write out all the tweets in the thread before publishing. He can easily add, remove, and rearrange tweets in the thread. He also finds the option to add relevant media to each tweet extremely useful.
Once he's happy with the thread, he publishes it with a single click. His followers can now easily read through the entire thread, retweet it, or reply to it. Sam feels satisfied as he can share complex news stories in a more accessible and efficient manner."

This usage scenario offers a vivid depiction of how Sam would use the new feature. It helps the team understand Sam's needs and expectations more clearly.

Usage scenarios add depth and clarity to the user stories. They help the team visualize the user's interaction with the product.

#14 Preconditions and Postconditions

Preconditions and postconditions are useful techniques from formal methods of software development, but they can also serve to write effective user stories.

Preconditions describe what must be true before a user story can be executed, while,
Postconditions define what should be true after the user story has been executed.

Imagine you’re part of a team working on Amazon’s online marketplace.

Persona: Mia," a busy professional who appreciates a seamless and efficient online shopping experience.

A basic user story would look something like this,

"As Mia, I want to check out my shopping cart easily so I can quickly complete my purchase."

This is a fine user story, but we can add preconditions and postconditions to make it more comprehensive. Here's how we can do that:

Preconditions:

Mia has an Amazon account and is logged in.
Mia has items in her shopping cart.

User Story:

"As Mia, I want to check out my shopping cart easily so I can quickly complete my purchase."

Postconditions:

The items in Mia's cart have been paid for using her selected payment method.
Mia receives a confirmation of her purchase.
The items in Mia's cart are set for delivery to her chosen address.
Mia's shopping cart is now empty.

In this revised version, we've laid out the conditions that need to be true before (preconditions) and after (postconditions) the user story is executed.

The postconditions serve as the story’s acceptance criteria.

#15 Emotional Mapping

Adding an emotional layer to your user stories.

In addition to describing what the user wants to do, think about how they might want to feel while doing it.

For example,

"As a user, I want to easily find a book so that I can start reading without feeling frustrated."

Using emotions in user stories can lead to a more human-centred design approach.

#16 Unexpected Twist

Add unexpected twists or turns to your user stories to encourage creative problem-solving.

These could be unusual constraints or challenges that force your team to think outside of the box.

For example,

"As a user, I want to be able to shop for groceries on the website even when I'm in an area with a very bad internet connection."

#17 Futurespective User Stories

Encourage your team to envision a successful future outcome and then work in reverse to define the user stories that will lead to that success.

The process starts with defining a future state that is ambitious yet achievable and then asking:

"What user stories helped us achieve this outcome?"

This reverse engineering method can help stimulate creative thinking and generate user stories that are strongly aligned with achieving your product's vision.

I was working with my team on RBC’s mobile banking app.

We defined an ambitious yet achievable future state like below:

"We have successfully launched a mobile banking app that's rated 4.5 stars on the App Store and Google Play, with reviews highlighting its intuitive design and feature-rich services."

Then I helped the team reverse engineer the journey to this successful future state. Here are a few examples of user stories we created.

"As a user, I want to easily link my bank account to the app so I can begin using the services without any hurdles."
"As a user, I want the app to provide insights into my spending habits, so I can better manage my finances."
"As a user, I want to be able to transfer money to my friends and family quickly and securely."
"As a user, I want to receive real-time notifications for any transactions, so I can stay up-to-date with my account activity."
"As a user, I want the app to have a feature to set financial goals and track them regularly."

This approach can help your team brainstorm user stories that are directly aligned with your product goals.

#18 Haiku 5-7-5

Haikus are a form of Japanese poetry that follows a very specific structure.

They are composed of three lines with a 5-7-5 syllable count.

This poetic format forces the poet to deliver a message or paint a picture in a very concise manner.

Applying this approach to user stories requires you to craft the story within the brevity of a haiku. The aim is not to strictly follow the 5-7-5 syllable rule, but to keep the user story concise and to the point, just like a haiku.

Let's say you're working with a team, developing a data analytics tool.

A typical user story might be:

"As a data scientist, I want to easily feed data into the AI tool so I can train my models more efficiently."

As a haiku, this could be stripped down to:

"Data scientist, feeds data, trains models."

The "User Story as Haiku" requires you to simplify the user story to its core components -

the user,
their action, and
the benefit that follows.

It's an enjoyable and imaginative exercise, but it also serves as a valuable tool in keeping your user stories straightforward, concentrated, and in line with the user's requirements.

#19 Multidimensional User Stories

This one involves considering different dimensions while creating a user story.

Instead of focusing solely on what the user wants to do, you also consider when, where, why, how, and with whom they want to do it.

Example of a typical story:

“As a Twitter user, I want to be able to customize my feed so I can see the content that's most relevant to me."

A multidimensional user story will look something like this:

"As a Twitter user, I want to customize my feed when I'm commuting home from work, using simple toggles, so that I can catch up with the news and posts that interest me the most, from the users I value."

Note: You can split these into multiple user stories.

This will help your team to come up with a more well rounded solution.

This is it 🙏

If you have any questions (related to this topic), don’t forget to use the comments section to ask.

💡 1 Tip to get noticed at work

Always rock a notepad when you head into a meeting. Trust me, people will love that you're kicking it old-school.

Instead of writing down every little thing, try to catch the main buzzword or phrase from each point someone makes. It’s a cool trick to keep things concise.

While you’re scribbling down, toss in a nod here and there. It’s like a universal “I’m tracking with you” signal.

And if someone pokes their nose into your note-taking style, just play it cool and mention these are just your quick personal takeaways.

🙋🏻‍♂️ Your Questions!

If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.

If you’re finding this newsletter valuable, consider sharing it with friends or subscribing if you aren’t already.

Share Winning Strategy

Till next week!

Sincerely,

Vibhor 👋

P.S. Let me know what you think! Is this useful? What could be better? I promise you won’t hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.

“I share things I wish I knew in the starting years of my career in the corporate world"

Vibhor Chandel