# 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** <a href="#example-user-story" id="example-user-story"></a>

**Use Case:** Book workout

**Primary Actor:** User&#x20;

**Stakeholders:** Marketing, Coach Education, Scheduling

**Trigger:** User wants to book his/her next workout (or has been reminded by a notification)&#x20;

**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**
