A Guide On How To Craft User Stories — Part 1

I share with you a user story template that I have been evolving for years and has helped me with different product teams.

For many product managers, part of breaking down requirements into small pieces of development is crafting user stories. But creating user stories that resonate with both stakeholders and the development team is a big challenge, especially when it comes to delivering value to the user.

In this guide

• 📚 Where does the term “User Story” come from?

• 🛠️ What do you need before writing user stories?

• 🗺️ Start with Story Mapping

• ✍️ How I craft user stories

• 📝 User story exercise (a template to copy!)

• 💡 Advice and best practices

Where does the term “User Story” come from?

After some research, I was shocked to learn that user stories existed before Agile. Many professionals believe, as I do, that user stories were born as a consequence of Agile software development. But that is no longer the case. 😶

Historically, Ken Beck invented the term in 1997, but it wasn't until he published his book Extreme Programming Explained in 1999 that user stories became part of the core software development planning process.

Later, Bill Wake created the INVEST checklist that we know as of now and Mike Cohn’s popularized this in 2004 for Agile development.

Why is this relevant?

I believe that understanding history can help us to broaden the way we perceive certain processes or activities. Especially, when there is a strong movement against agile development as a consequence of wrong practices and bad decisions. But that's a topic for another day.

Incorporate everything positive that will help you achieve good results.

So after this short disclaimer, let’s keep learning! 📖

What do you need before writing user stories?

The secret of launching a product feature that hits the mark so good starts much earlier in the development process. Yet before diving into the essentials, let's clarify what user stories are: they are short, simple descriptions of a feature told from the user's perspective. They typically follow a simple template:

But creating compelling user stories is not just about writing, it's also about understanding users and empathizing with them. The product manager's role is to identify customer needs and the broader business objectives that a product or feature will fulfill.

If you like or have played with Lego's, as I have, you can see user stories as little building blocks and how product managers can steer the course of what needs to be built.

Basically, to build the next Lego house, every product manager needs:

• Identify and understand the product goals and its vision

• Understand the product audience:

  • Directly interact with your users through interviews, surveys, or feedback sessions.

  • Create personas to better understand user needs, behaviors, and pain points.

• Break down the big picture:

  • Map out the user journey to uncover key functionalities that need to be developed.

To move on to the next phase I recommend you read this post where I explain how you can create your product strategy. This strategy will help you identify the key features to focus on.

Start with Story Mapping

After you have a product strategy with key product features identified, draft your first story map by framing the user journey. Story Maps are a great way to identify user stories, after breaking down big epics into smaller tasks.

https://plan.io/blog/user-story-mapping/

In order to create your story map needs to answer the following:

• 🚙 WHAT

  • What is the problem to solve?

  • What is the product to build?

  • What is the new feature to add?

• 👤 WHO

  • Who is the user or audience that will use it?

  • What are the benefits to them from this development?

• 🛣️ WHY

  • How will offering this to users provide value in the end?

  • What benefits will the company get after building it?

When I have the answers to these questions I usually feel confident enough to start visualizing what is needed and in what phases. It depends on one's level of experience and, of course, there are products that require a deeper level of expertise.

To effectively address all aspects of a product, it is important to have a range of perspectives in your team. This usually requires conversations with domain experts, testers, UX designers, stakeholders, and developers. They will bring knowledge of users and functionality.

Stakeholders, on the other hand, provide insight on how the software will generate revenue for the company, and engineers offer expertise on the technical aspects and timeline for building the product.

They will help you shape your story mapping with their feedback and get a clear final picture of what needs to be developed. After that, I start crafting user stories for development. 🗒️

How I craft user stories

When I started in product management, it was hard to find more in-depth examples of user stories. Even my colleagues at the time wrote them very differently.

I bet every PM has their own way of writing requirements or stories. That's part of what makes us unique.

If you think about it, stories serve as a communication path between developers, architects, designers, stakeholders, etc. with a focus on the user. Building this bridge rests on the shoulders of the product manager.

User story template

Now, let's review a template that I have been perfecting over the last years. For each functionality, I’ll focus on 4 main sections:

• Goal or Purpose: Personally, I like to inform my teams why developing this story matters. So I try to articulate here what is the expected goal. This is also helpful for our Definition of Done, meaning, it helps answering if we achieved the goal or not.

  • What are we trying to accomplish here?

  • Clear purpose of why this matters

• User Story: This is the typical user story structure developers are familiar with:  As a [type of user], I want [a goal] so that [benefit]. It should answer:

  • What does the user needs?

  • What is valuable to the user?

• Acceptance Criteria: These are usually presented as a set of statements or bullet points describing specific conditions or tasks. Although I like to do a mix of user scenarios using Gherkin to easily explain what the user will see or receive.

  • Functional Criteria: What the system should do, how it should react under certain conditions, or how it interacts with users.

  • Non-functional Criteria: Quality attributes such as performance, usability, reliability, etc.

  • Constraints: Any limitations or conditions the solution must adhere to. What should the system do in case of error?

• Risks and Dependencies: These include any potential obstacles or external factors that may impact the development or implementation of the user story.

  • Technology constrains

  • System or project dependencies

  • Legal compliance, data privacy

User story template

User Story exercise

Let's say you work for Bank of America Corp. In fact, you are the product manager for the bank's new mobile app. You have identified the main features the app needs to satisfy the users of your product, which are bank account holders.

One of these key features is receiving alerts for account transactions. After interviewing some customers, they expressed their fear of not being aware of whether there is specific activity or transactions in their bank accounts, and opening the app multiple times a day to check if everything is in order sounds illogical.

So what would this look like with the structure I use? 🤔

Bank feature user story example

Feature: Transaction Alerts Via Push Notifications

Goal

Enhance the security and user experience of our mobile banking app by allowing users to receive real-time, customizable transaction alerts directly to their smartphones.

User Story

As a bank account holder, I want to be informed immediately of any transactions, so that I can be aware of my account activity and take action.

Acceptance Criteria (with Gherkin)

Scenario: User accepts to receive notification

Given the user is on the app Notification Settings
When he turns on push notification preference
Then he is prompted to allow push notifications on his device

Scenario: User can opt-in or opt-out

Given the user is on the app Notification Settings 
When the user toggles the push notification preference
Then their choice is saved immediately

Scenario: The app respects the device's Do Not Disturb settings

Given the device is in Do Not Disturb mode
When a push notification is triggered
Then the notification is not delivered until Do Not Disturb mode is turned off

Risks and Dependencies

• Technical Risks: Relying on real-time systems to send notifications instantly. Any performance issues could cause delays, affecting the feature's effectiveness.

• Dependency on External Services: Dependence on third-party services for processing and enriching transaction data which could affect reliability and accuracy.

• User Privacy Risks: Need to manage sensitive financial data securely in notifications to meet strict privacy laws like GDPR.

In my experience it takes some time to come up with a way of writing user stories like this. What’s most important is that every single person is aligned on the same page.

Here is the template you can download or copy and paste this image into your favorite diagramming tool and start unleashing your creativity.

User Story template

To come up with this base I had to learn from many mistakes, here’s more advice that you can follow.

Advice and best practices

Gherkin facilitates QA testing

I like Gherkin because one of the most significant benefits is Gherkin's support for automated testing. When you express acceptance criteria in Gherkin, teams can easily translate these into automated tests, paving the way for Behavior-Driven Development (BDD).

In essence, Gherkin serves as a versatile tool, bridging the gap between technical and non-technical team members by delivering a clear, concise, and shared understanding of project goals and requirements.

Listing risks and dependencies at user story level

In my experience, this visibility helps engineers navigate complex projects, prioritize tasks, allocate resources effectively. Also, provides all project stakeholders with a clear view of potential issues, increasing transparency and informed decision making.

The perfect user story does not exists

There is no such thing as a perfect user story. I don't think anyone can really tell if you're doing them wrong. But if your stories are actually confusing rather than helping the development team achieve their goal, then you should be looking what to improve.

You can use INVEST as a guide. INVEST focuses on creating manageable, valuable and efficient work units.

Some advice on crafting your INVEST-able user stories:

• 🧩 Strive for Independence: If possible, minimize overlaps and dependencies to ensure straightforward scheduling and implementation.

• 🤝 Maintain Negotiability: Write stories that invite discussion and adaptation, focusing on goals rather than specifics!

• 🎁 Prioritize Value: Always link your story back to user benefit.

• 📏 Make It Estimable: Provide enough detail for the team to estimate effort without being overly prescriptive.

• 🔎 Keep It Small: Break down complex features into manageable stories.

• ✅ Ensure Testability: Include concrete acceptance criteria for testing.

💡 Remember, what matters of all of this is that the product functionality meets customer’s expectations. You can craft as many well-written user stories as you want. But that doesn't guarantee that you're going to meet your customer's expectations in the next release.

In this sense, don’t try to write the perfect user story, requirement or documentation. But do make sure your team has understood perfectly what users are expecting from their development.

If you can get engineers to relate the results of their work strictly directly to the user experience and empathize with them, then you're on the other side.

That’s all for today, I hope you had enjoyed this issue so much. Let me hear from your experience in the comments and feel free to re stack this post with your thoughts as well! 🙏