# Agile - User Stories **Initiatives、Epics、Stories** Every software team has a process they use to complete work. Normalizing that process–i.e., establishing it as a workflow–makes it clearly structured and repeatable, which, in turn, makes it scalable. From the largest objectives down to the minute details. You’ll want to be able to respond to change, report your progress, and stick to a plan. Epics, stories, themes, and initiatives are precisely the tools. * **Themes** are large focus areas that span the organization, like organization goal that drive the creation of epics and initiatives. * **Initiatives** are collections of epics that drive toward a common goal, like a product roadmap. * **Epics** are large bodies of work that can be broken down into a number of smaller tasks/stories. * **Stories:** also called "user stories" are short requirements or requests written from the perspective of an end-user. ![](/files/-MZnbaH1C0T8xYCHX5k7) **What are the steps to write great Agile User Stories?** A common User Stories template has a specific workflow to help deliver: 1. Make up the list of your end-users. Define what their "pain" or "need" is, which you’re trying to solve. 2. Define what actions they may want to take. 3. Find out what value this will bring to users and, eventually, to your product. Also, ask yourself - will any party pay us for this? 4. Discuss acceptance criteria and an optimal implementation strategy. **Step 1: Think of the "Who"** This is the first and, maybe, the most fundamental step. Before writing a User Story you should actually know who the end-users of your product are. And more important - what needs they have, which you are trying to cover. * **It’s all about the user.** Not about developers. And even not about a Product Owner. Each Story should be valuable to some group of your end-users. * **Don’t think of users only as external customers.** It’s true that your Stories will be mostly about them. But it’s also true that you have to consider internal users such as admins, editors etc. * **Feel some empathy.** Give your "user" a name. Think of his mobile habits, what issue your app is going to get resolved for him and how you’re going to make this path easier and faster. Remember some people who you know from real life and who fit this portrait; feel how you relate to this target group. **Step 2: Think of the "What"** Now we have a few groups of end-users. The next step we do is define what functionality each user expects, how he’s going to interact with the app. These are the main rules to remember when writing an action for a Kanban or Scrum User Story: * **One action per Story.** If you want to write something like "as a customer I want to browse items and add them to the cart" you’d better split it into 2 separate Stories. * **Describe an intention, not a feature.** For example, instead of "I want to manage my profile" create a few Stories like "I want to be able to register", "I want to upload my profile photo", "I want to link my credit card to my profile" - each Story will have a different value. * **Keep it short.** Users don’t care what library you will use to let them browse the list of items so leaves all the tech details aside. * **Avoid describing UI.** We’ve defined Stories as negotiable, remember? That's why all good User Story examples don't include any UI details. So don’t try to compose any special way to implement them (we’ll do this later). **Step 3: Think of the "Why"** Finally, the last piece of our User Stories template is dedicated to a value that users get after performing an action. However, your \[so that] section should always correspond with your metrics and KPIs. It should either improve the UX, increase retention rates, shorten users’ journey to the issue solution or whatever. Each Story should contribute something to the general goal of your product. If you can’t answer what value this feature brings to end-users and your product as well, then you’re doing something wrong. For instance, there are a few User Stories examples with a well-written value for our ongoing food ordering app project: * As a customer, I want to get notifications when there are new hot offers so that I never miss the best deals. \[how it affects KPIs: users get notified ➡️ they use the app more often ➡️ retention rate grows]. * As a restaurant manager, I want to complement the dish description in the menu with a photo so that it looks more attractive to the customers. \[how it affects metrics: users are satisfied that they can see photos ➡️ sales grow ➡️ your revenue also grows]. **Step 4: Discuss a Story** Finally, we always discuss User Stories after they’ve been created. Even if it seems like nothing to talk about. Use the following tips when working on this task: * **Start with Epics.** It’s usually easier to move from more complex tasks to more specific ones so try writing Epics and then split them into Stories. * **Listen to feedback.** Sometimes you don’t need to guess Stories - ask your real end-users for feedback and use their ideas as a source of inspiration. * **Don’t introduce details too early.** It’s better to hold the brainstorming session before each sprint to discuss how to implement planned Stories. **Resources** * [**The 2020 Scrum Guide**](https://scrumguides.org/scrum-guide.html) * [**Scrum Glossary**](https://www.scrum.org/resources/scrum-glossary) **Requirements** * Functional requirements * relates to a result or behavior provided by a function of a system —> * Input --> Behavior --> Output * Process descriptions * Specific functionalities * Calculations —> "What a system should do" * Non-functional requirements * primarily specify how a system should behave and are constraints on system behavior * Product properties * User experience * Performance * Quality attributes —> "How a system should do it" * How to identify requirements * Analysis Techniques: * Observation (i.e. shadowing) —> basic attr * Questioning (i.e. interviews or surveys) —> performance attr * Creativity (change of perspective or brainstorming). —> excitement attr * Requirements in user perception * "The Kano-Model" * Basic attributes * Performance attributes * Excitement attributes **Theory** * Requirements vs User Stories | Requirements | User Stories | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | |

—> Waterfall methodology

|

—> Agile methodology

| Example - password reset: | Requirements | User Stories | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | | "As a user, I want to reset my password myself so that I can log in again." | * Role of User Stories in agile methodology * Why to choose User Stories in agile projects * **Simple** and **informal** description of how a system or product generates **value** for the **user** * **Basis** for **communication** between product owner and stakeholders * Rough documentation of the requirement, **refinement** takes place in collaborative **discussion** * The **completion** of the requirements is only achieved through **discussion** and can be recorded in **subtasks** * **Limited** **scope** is ideal for the implementation of **increments** * **High transparency** and a **common understanding** * How to implement User Stories * Completely refined User Stories are collected in the **Product Backlog** as so-called **Backlog Items** * Backlog items represent work packages **prioritized** by the **Product Owner** * The Product Backlog is continuously **reprioritized** and **extended** with new Backlog items * In the **Sprint Planning**, the User Stories are **scheduled** for implementation in the order in which they were prioritized in the Backlog * The **implementation** of the User Stories takes place in the scope of the respective **development sprint** [**https://medium.com/@yicheng\_/initiatives-epics-stories-94d302a88048**](https://medium.com/@yicheng_/initiatives-epics-stories-94d302a88048) **How to write User Stories** * Structure * **Short sentences** and short paragraphs wherever possible * Avoid **unclear nested sentences** and **ambiguous** references * Only **one requirement** per sentence * Use **consistent terminology** * Use **sentence templates** * Use of sentence templates **As** \, **I want to** \ **so that I can** \. * * Easy to **learn** and to **apply** * Automatic reduction of **linguistic effects** * Stylistically **uniform** requirements prevent misunderstandings * Can be used for almost **all types of systems** * requirements of **high quality** through the **defined variables** Variables * \ —> who is it for? (User) * \ —> What should be done? (Objective) * \ —> why should this be done? (Benefit) * Three C’s * **C**ard * Fit on a **Note Card** * **Concise** format —> Sentence template * Only **necessary information** * **Invitation** to have a **conversation** * **C**onversation * Gain **further details** * Promotes **collaboration** * Common **understanding** * Involve **PO**, **stakeholders** and **project team** * Real **value** of the user story **evolves** * **C**onfirmation * **Essential** requirements * Documentation as **testable** criteria * Confirm **correct implementation** **—> Acceptance Criteria** * Acceptance Criteria * Clarify **what** should be **implemented** * Documentation of the **implementation conditions** * Describe **functional requirements, system behavior** but also non-functional aspects * Must be defined **before implementation** * Are **required** for a Story to meet the **Definition of Ready** * Help to understand when a story is **"done"** (Definition of Done) Example: "As customer, I want to select a color so that I can see all clothes in this color." * In a filter section it must be possible to select common colors as filter criteria * A multiple selection of colors should also be possible * The filter must be able to be used in combination with other existing filters * The color must be stored and must be accessible on each piece of clothing * When the filter is applied, a database query returns only the clothes in the matching color * The filter can be switched off by clicking on the color again Online Resources referring to Sentence Templates and the three C’s: * **The Three C’s of User Stories** * **Writing User Stories** * Definition of **Ready** (DoR) * Describes when a User Story is **ready** for **implementation** * Defines which **criteria** have to be met to drag a story from the **product backlog** into a **sprint** * Ensures a **common understanding** of what needs to be implemented * Enables realistic **estimation** and **planning** * Reduces subsequent **effort** and increases **productivity** * Should be defined and implemented in **every agile project** * **INVEST** criteria for **quality** control * **I**ndependent – they can be developed in any sequence and changes to one User Story don’t affect the others. * **N**egotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow. * **V**aluable – each User Story delivers a detached unit of value to end-users. * **E**stimable – it’s quite easy to guess how much time (scope and size) the development of a User Story will take. * **S**mall – it should go through the whole cycle (designing, coding, testing) during one sprint. * **T**estable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately. **BENEFITS**: **Keep you focused on the business value.** It helps to make your app not only well-built from the technical perspective but also useful to the end-users. **Enable creativity.** Since it contains a minimal amount of info, your team is free to drive creative ideas to find the best solution to implement a Story. **Your project becomes more manageable.** We at Stormotion know that it’s a way easier to work with small and estimable Agile User Stories rather than with big complex tasks. **They inspire the team!** Every developer loves this sweet feeling of a small win which motivates him to work even harder. —> Examples for **DoR**: * * * The **user story** is documented in english language based on the defined template * The **Business value** is clearly articulated by the Product Owner * The **acceptance criteria** must exist, are testable and undersood by the team * The user story has been **estimated** by the team * **Legal**, **data security**, and **data protection** related aspects are **considered** * **Financing** is secured * **Dependencies** are identified and described * Definition of **Done** (DoD) * Establishes a **common understanding** of when a user story is considered **done** * Ensures the **quality** of the feature to be delivered * **Apples to** all Backlog items * Not to be **confused** with **acceptance criteria** * Final **check** before delivery —> Examples for **DoR**: * **Acceptance criteria** defined in the User Story **are fulfilled** * **Deployment** to the **Test** environment was successful * An **acceptance test** on the Test environment has been **performed** and **approved** * **Documentation** was written in English * **Integration tests** with interfaces have been conducted * Implementation meets the **Coding Guidelines** **When to split User Stories?** * **Why** do user stories have to be **split** * When a user story is **too big** for a **sprint** * If **too many requirements** are described in one User Story * If the requirements in a User Story are **too complex** * If parts of the User Story are **not needed** * **Benefit** of splitting User Stories * Easier to **understand** * **Less refinement** required * Allow a more **accurate estimation** * Easier to **prioritize** by the Product Owner * **Faster implementation** and feedback * Higher probability to meet the **Definition of Done** * **How** to **split** User Stories * Simple/Complex * Operations (CRUD - Create, Read, Update and Delete) * Workflow Steps * Major Effort * Business Rule Variations * Data Entry Methods * What to consider **after splitting**? * Are the split stories **comparable** in **size?** * Do the split stories meet the **INVEST criteria**? * Is a **reprioritization** necessary? * Is it possible to **delete** some of the split stories completely? * Were the **estimates** adjusted after the splitting? **Reading Recommendations** Title: User Stories Applied: For Agile Software Development Author: Mike Cohn ISBN-13:978-0321205681 Title: User Story Mapping: Discover the Whole Story, Build the Right Product Author: Jeff Patton ISBN-13:978-1491904909 Title:Scrum: The Art of Doing Twice the Work in Half the Time Author: Jeff Sutherland ISBN-13:978-1847941107 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://stephanosterburg.gitbook.io/scrapbook/coding/agile-user-stories.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.