Writing Effective User Stories
Every interaction with or within _______ products is, in fact, a user story. Each user story has a primary actor (e.g. coach, customer, system, scheduler, customer service agent, etc.) and stakeholder (everyone interested in this user story working). Also, it always has a start (= a trigger), an end (= an end-condition) and one or multiple steps in between.
It is important to provide enough context to explain why the actor wants to perform this action and what his/her desired outcome is. Also, provide information where in the larger journey he/she is located.
The main success scenario describes the minimum necessary steps to the desired goal of the primary actor (= success end-condition). Any detailed specifications, extra steps or alternative scenarios then become extensions. To show priorities within the extensions we group them into versions. All extensions contributing to achieving the main success scenario are success extensions. All extensions that are handling failures (e.g. failed end conditions) are failure extensions.
Every user story should consider pre-conditions, failed end-conditions and designs or supporting documents (= assets).
Each step of the scenario, the pre-conditions, and the extensions then potentially are (or become) their own user story with their own primary actors. In those cases, the accompanying confluence article should be linked directly into the document.
IMPORTANT
If you encounter external tools not owned by product (example lever, autopilot) → don’t create user stories
Write a rough overview of the entire process showing where product ownership ends, what happens externally (very rough) and where ownership starts again
Whenever there is ownership of product there should be a user story
NEXT STEPS
If you find inconsistencies or issues in user stories → maybe it is time to test some assumptions and introduce a feature
Example User story
Use Case: Book workout
Primary Actor: User
Stakeholders: Marketing, Coach Education, Scheduling
Trigger: User wants to book his/her next workout (or has been reminded by a notification)
Context of use (2-3 sentences): The user wants to search for a workout. Visits the BEAT81 dashboard, applies filters and selects a workout and clicks the booking button to book the workout.
Preconditions (optional): Task xyz must be finished
Success End Condition: The user sees a confirmed booking in the app
Failed End Conditions:
The user could not find a suitable workout
The user was stopped from booking by the system
MAIN SUCCESS SCENARIO
The user opens the app
The user goes to the schedule overview
The user sees a list of suitable workouts relative to his location
The user selects a suitable workout
The user books the workout
The user sees a confirmed booking in his app
SUCCESS EXTENSIONS
Version 1.0 LIVE :
3a. Location-based filter
The user can select a location from a pre-populated list of nearby locations
The user clicks on “apply” to apply his filter
The list is refreshed accordingly
3b. Date/time filter
The user selects a date and time in the future
The user clicks on “apply” to apply his filter
The list is refreshed accordingly
OUTDATED: CHECK 1.2
Version 1.1 IN PROGRESS :
2a. Link with pre-filtered lists
The user clicks on a specific link
The user sees a list of pre-filtered workouts depending on the link
Version 1.2 FUTURE VERSION :
XYZ
LINKS TO FEATURE ARTICLES OR SUB-STORIES
Last updated