My previous product management articles focused on more philosophical topics (you may find them here: the first was about the product vision, and the second was about the product's lifecycle stages). Today, we move closer to the product manager's everyday routine. Let's talk about user stories — an elegant approach to determining features in Agile.
What is a User Story?
A user story is a description of some functionality given by its actor.
They came into play in the late 1990s with the Agile software development methodology, where user stories replaced long, detailed requirements documents. Quickly, they became an essential element of Agile practices, finding their way into other methodologies like Scrum.
The user story consists of three simple parts:
A typical user story looks like this:
As a [user role], I want [goal] so that [reason/benefit].
They came into play in the late 1990s with the Agile software development methodology, where user stories replaced long, detailed requirements documents. Quickly, they became an essential element of Agile practices, finding their way into other methodologies like Scrum.
The user story consists of three simple parts:
- Role — who the actor is. Customer, student, seller, anyone.
- Goal — what they want to achieve.
- Reason — why they want it.
A typical user story looks like this:
As a [user role], I want [goal] so that [reason/benefit].
Why Do You Benefit from User Stories
Why would you choose this approach instead of old good requirements specifications? Honestly, you may not. You may use both. Just consider that adding user stories will probably improve your performance. And this is why.
User stories make user needs the central focus of the development process. We conduct any task keeping in mind why our users want it and what they expect from the feature. It even sounds good, right? User stories help enhance communication within the team and support flexibility and adaptability (which is crucial in Agile).
When working with user stories, each team member repeatedly deals with the user's motivation, increasing opportunities for improvement and innovation within the team.
User stories make user needs the central focus of the development process. We conduct any task keeping in mind why our users want it and what they expect from the feature. It even sounds good, right? User stories help enhance communication within the team and support flexibility and adaptability (which is crucial in Agile).
When working with user stories, each team member repeatedly deals with the user's motivation, increasing opportunities for improvement and innovation within the team.
How to Write Great User Stories
There is a model widely used to define a good user story called INVEST — a good user story must be Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Let’s go through these points one by one.
Independent. It means that the user story can be developed and delivered independently of other stories.
Negotiable. Flexibility is a must. The PM and other team members might discuss what this particular user story should include further.
Valuable. The user story must deliver value for the end user.
Estimable. The development team must be able to estimate the required efforts to implement the user story. If estimation is impossible due to complexity, you should break it down into more straightforward stories.
Small. The user story must be small enough to be implemented during one sprint.
Testable. The user story must have an explicit acceptance criterion that allows us to determine whether it is implemented correctly.
If you validate your user stories against these points regularly and encourage your team to pay attention to them, it will help you to gain maximum from this approach.
As the author, I want to give you some examples to make this article more useful.
Let’s go through these points one by one.
Independent. It means that the user story can be developed and delivered independently of other stories.
Negotiable. Flexibility is a must. The PM and other team members might discuss what this particular user story should include further.
Valuable. The user story must deliver value for the end user.
Estimable. The development team must be able to estimate the required efforts to implement the user story. If estimation is impossible due to complexity, you should break it down into more straightforward stories.
Small. The user story must be small enough to be implemented during one sprint.
Testable. The user story must have an explicit acceptance criterion that allows us to determine whether it is implemented correctly.
If you validate your user stories against these points regularly and encourage your team to pay attention to them, it will help you to gain maximum from this approach.
As the author, I want to give you some examples to make this article more useful.
Typical User Stories
Here are some examples of user stories for platform products. Pay attention that in a platform, you usually have several different roles that interact with your product in different ways.
Social Media Platform
Educational Platform
Social Media Platform
- As a user, I want to follow other users and see their posts in my feed so that I can stay updated with their activities.
- As a content creator, I want to schedule my posts in advance so that I can manage my content calendar efficiently.
- As a community manager, I want to moderate comments on posts so that I can maintain a positive and respectful community environment.
Educational Platform
- As a student, I want to submit my assignments online so that I can receive feedback from my instructors.
- As a teacher, I want to create and manage quizzes for my courses so that I can assess student understanding.
- As a course administrator, I want to track student enrollment and progress so that I can manage course offerings effectively.
What to Avoid in User Stories
If you decide to try this approach, be careful not to make these common mistakes:
- Vague user stories. They must be precise; otherwise, they will not work for you. Double-check yourself initially, and ask your team if there is any ambiguity in your stories. But try not to overdo it, because next is…
- Overly detailed user stories. While user stories must be very specific, they must still remain concise. It may be hard to find a balance right from the start, so I recommend aligning your understanding of what is needed with your team as often as possible. You will later become more confident, and they will understand you better, but in the beginning, you better be sure that everyone is on the same page.
- Lack of User Involvement. User stories will work if only their main ingredient — end user's motivation is caught correctly by the PM. It is always a good idea to check your thoughts on why users want this or that with users themselves.
Conclusion
User stories are an excellent tool for building your product primarily around user needs. They help your team remember that this particular functionality is being developed not for fancy screens and buttons themselves but to satisfy a particular user's intention. Doing so will significantly improve your chances of success.
Should you decide to give it a try, use the INVEST model to ensure your user stories are all good. Avoid creating them ambiguous or too detailed, and always communicate with users about their genuine motivation to take it into account within your product.
If you are interested in learning more about user stories, I recommend reading these books: "User Stories Applied: For Agile Software Development" by Mike Cohn and "The Art of Agile Development" by James Shore and Shane Warden.
Should you decide to give it a try, use the INVEST model to ensure your user stories are all good. Avoid creating them ambiguous or too detailed, and always communicate with users about their genuine motivation to take it into account within your product.
If you are interested in learning more about user stories, I recommend reading these books: "User Stories Applied: For Agile Software Development" by Mike Cohn and "The Art of Agile Development" by James Shore and Shane Warden.
