> For the complete documentation index, see [llms.txt](https://rokbehin.gitbook.io/processes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rokbehin.gitbook.io/processes/product-processes/writing-effective-user-stories.md). # 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** 1. The user opens the app 2. The user goes to the schedule overview 3. The user sees a list of suitable workouts relative to his location 4. The user selects a suitable workout 5. The user books the workout 6. 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**