Chp 7/17 : How to write user stories?
Prev: Chapter 6 — How to define MVP?
Next: Chapter 8 — How to Test & Validate MVP
[Back to — Product Management 101 ]
By now, you’ll have information on the challenges faced by the users (in different stages) and their possible solutions in form of features.
This is where user story helps us effectively communicate the detailed description of the features between the teams. The user stories help to keep everyone on the same page.
User stories are short, simple descriptions of a feature told from the user’s or customer’s perspective.
They typically follow a simple template:
As a < type of user >, I want < some goal >, (if applicable) so that < some reason >
The user stories help you communicate the functional requirement to the engineering team. Also, it helps the team understand why are they building the feature and how would it benefit the user or how would the user use it.
How to write user stories?
You should write user stories by writing an epic and then breaking it down.
Epics are big and abstract stories that are derived from personas and journey mapping.
It tells what should the product do for the user (corresponding to user goals provided in the Personas / Customer Journey Mapping.
Epics allow you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users.
Once, the epic is ready, you can break that down into smaller, detailed stories until they are ready: clear, feasible, and testable.
For example, an epic that describes a feature as
“I want to share my photo with my friends”
can be broken into -
I want to share my photo with my friends on Facebook, Twitter, Insta, WhatsApp.. these all form different user stories.
Let’s take the example used in Chapter 4 — Customer Journey Mapping Section — of a user booking a hotel.
Let’s consider one Epic in the Discovery stage -
As a user, I would like to see hotel search results on a map with appropriate filters and information.
The above Epic can be broken down further into smaller user stories -
“As a user, I should be able to view the results on a map, so that I don’t have to go back and forth between list view results and the location on a map”
“As I move the map to view some other region, the result should get updated as per the new location”
“As a user, I should be able to view the information I require (Price, Rating Score, Star, Photos) on the map view itself”
“As a user, I should be able to apply filters (price, rating) on the map view itself”
Taking the example of the journey mapping of a cab-hailing service, we can write following epics that could be broken into further small user-stories.
User Story Acceptance Criteria
Once, you have created the user stories, add the acceptance criteria for the user stories.
Acceptance Criteria allow you to describe the conditions that have to be fulfilled so that the story can be marked as done. The criteria enrich the story, they make it testable, and they ensure that the story can be demoed or released to the users and other stakeholders.
Consider the first user story in the previous example,
“As a user, I should be able to use my location so that I can see available cabs near me”.
The acceptance criteria would be -
- The app should be able to detect my location and point it on the map.
- The app should be able to take an input from any location text and point it on the map.
- Once, the location has been determined, the nearby available cabs should be displayed on the map.
A criterion to assess users stories is I.N.V.E.S.T.
- Independent: User stories should be independent as any dependency would make it difficult to prioritize them one over the other
- Negotiable: The implementation details are not specified and are left to the team
- Valuable: User stories should have value to the customers
- Estimable: They should be broken down into the simplest form that the team can work with
- Small: They should be small enough to be finished within a sprint
- Testable: The incremental deliverable should be testable against the acceptance criteria specified
Where to write these user stories?
You could use the solution as simple as Google Sheet to advance solution like Trello, Jira, Aha, Craft and many other tools.
Estimating User Stories
Effort estimation is hard. That’s because traditional software development teams provide estimates in a time format — hours or days. However, many teams (that follow Agile Development practice) use story points based estimation.
Story points is like a currency that tells you how much effort would be required to develop a user story (but) in relative term.
Story points rate the relative effort of work in a Fibonacci format of — 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
This abstraction helps the team to make tougher decisions about the difficulty of work with lesser efforts.
The following matrix (by Dan Olsen) would be helpful in guiding how to allocate story points to a user story.
In simpler terms, you could also allocate story points based on the following definition -
1 Point — I understand exactly what needs to be done, and exactly how to do it.
2 Points- I understand exactly what needs to be done, but I’m going to have to do a little bit of research or experimentation to figure out how to do it.
3 Points — I mostly understand what needs to be done, and kind of understand how I would do it. (But there is not enough uncertainty here to reject the story altogether as invalid.)
User story having story point higher than 5 or 8 is usually broken down to form smaller stories.
Planning Poker Estimation Technique
In this method, the team members are handed cards which have numbers based on the Fibonacci series written on it.
The facilitator (generally Product Manager / Owner) provides a short briefing about a user story, for which the team members display cards. Any differences in the estimates are discussed. Usually, the team arrives at a consensus after round one-two owing to the discussion of the lower and the highest estimates.
Relative Estimation
Sometimes, a team might have a large number of user stories to estimate. In such scenarios, Relative Estimation technique might prove to be better.
The stories are sorted depending on its size, varying from the smallest to the largest. Generally, T-shirt sizing (XS, S, M, L, XL, XXL) are used for providing the estimates for the user stories.
However, in order to start estimating, you’ll require to set a scale using past user stories. It would be a good idea to populate a cheat sheet -
The good thing about story point is they easily capture all the factors impacting work tasks -
- Amount of Work
- Complexity of Work
- Associated uncertainties or risks
In the next chapter, we’ll see how to validate your MVP.
Previous: Chapter 6 — How to define MVP?
Next: Chapter 8 — How to Test & Validate MVP
[Back to content page — Product Management 101 ]
Want to learn more?
Enroll into Product Management:A-Z — The complete product management online course with 25+ chapters, 40+ live assignments and product interview tips . Built with inputs from experienced Product Managers working @ Top Tech firms like Google, Adobe, Amazon; the course has 500+ enrollments from 40+ countries.
Book Mock Interviews with product experts to practice your interview skills & get detailed feedback.
Check out PM Interview Questions — An exhaustive list of unique Product Management interview questions answered by product experts.
Click 👏 if you found this useful. SHARE to help others find this article.
It gives me 🔋 to write knowing people find value in it.
Originally published at zapupp.com
