Creating a user story, is a crucial part of a Product Manager’s daily routine. It’s a simple and informal way to define new features for digital products from the user’s perspective. When done right, it adds significant value during the development process.
As I celebrate my third year as a PM (Product Manager), I want to share a straightforward structure that I’ve refined through iterations.
As I’ve crafted one task after another, I’ve pondered questions like:
- How can I make this better?
- How can I define the problem without focusing on the solution?
- Is it better to define it 100%, or collaborate with the team during sprint planning?
- How can I write something that’s both general and specific, providing developers with room to find the best solution while defining the scope clearly to avoid endless development?
It’s a challenge I grapple with constantly.
So, where do we start? We begin with the widely recognized User Story, which consists of three parts:
🙂 As [Type of Person]
💡 I want to [Action]
⭐️ So that [Outcome]
Now lets understand each field!
Let’s imagine we want to create a new feature that allows a user to log in and access an application:
🙂 As a User
Type of Person: This answers the question, “Who is this story for?” It could be the end user of our product or the team on whom our development relies. Knowing this is essential, and the team should be aware of it from the start.
💡 I want to log in to my account
Intention or Action: This is the core of what we want the user to do. What’s the new feature we’d like to add? By this point, we should have conducted research and validation to be confident it will enhance our product.
⭐️ So that I can access my user account
Expected Outcome: This part defines what should happen in our product when the user takes action.
Let’s build our first user story:
🙂 As a User
💡 I want to log in to the application
⭐️ So that I can access my user account
But something is still missing: the different scenarios our development must consider to avoid unexpected issues. These are the acceptance criteria. I usually draft a set of possible scenarios, often using the Gherkin syntax (Given, When, Then).
Let’s define our use cases for creating a login:
Acceptance Criteria 👍
Given that I have entered my correct email and password When I click “Log In” Then I can access my account
Given that I have entered an incorrect email and password When I click “Log In” Then I remain on the same page and see an error message stating that the login details are incorrect
Given that I haven’t entered an email or password Then the “Log In” button remains inactive
Given that I have entered my correct email and password When I click “Log In” and the application returns an unexpected error Then I remain on the same page and see an error message indicating that an error has occurred
Given that I clicked on “Forgot my password” Then I am redirected to the “Forgot my password” flow
Given that I clicked on “Create an account” Then I am redirected to the “Create an account” flow
With these complete acceptance criteria, our user story is ready to be shared with the team for review, corrections, or any additional details.
Depending on the type of ticket you’re creating, you can always add context, sequence diagram, information, or files that help provide an even better understanding of the task.
As you can see, this is a straightforward way to write user stories, promoting natural explanations and minimizing misunderstandings.
Let me know how you would approach this and if you’d add or modify anything in the definition. 🔥
