# User Story ## User Stories A user story is a short description of a feature or functionality told from the perspective of the user. It captures what a user needs to do and why.
### Writing User Stories Some guidelines for writing good user stories: * Start with: > *"As a \[**user role**], I want \[**goal/desire**] so that \[**benefit**]."* * Write in simple, non-technical language focused on the user need * Limit to small, distinct pieces of functionality that can be built in one sprint * Use themes and personas to frame the user perspective * Include just enough detail for developers to understand the scope ### Acceptance Criteria Acceptance criteria defines the boundaries of a user story and what must be done for it to be accepted: * Specified in bullet point form under the story * Acts as input for test cases * Includes functional, non-functional, and UX requirements * Focuses on business and user value vs. technical details ### Grooming User Stories The backlog is groomed through discussion of user stories: * Assess clarity, dependencies, risk, assumptions * Split or merge stories as needed * Estimate effort by agreeing on story points * Prioritize stories based on business value This process ensures stories are ready for the team to execute in a sprint. ### User Story Lifecycle User stories move through states of writing, grooming, sprint planning, implementation, testing, and completion based on acceptance criteria. ### User Stories in Agile User Stories, as their name suggests, center around the requirements and experience of users. As a result, they incorporate the first principle of the Agile Manifesto: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. #### What makes a good User Story? User Stories evolve over time from vague, nebulous concepts into specific, well-articulated needs. A good way to assess whether a User Story is well defined is to use Bill Wake's **INVEST** mnemonic. The INVEST mnemonic encourages teams to ask the right questions of their User Stories or Product Backlog Items (PBIs). Your User Stories, as the table below shows, should be: Independent, Negotiable, Valuable, Estimable, Small, and Testable. ### INVEST
Independent Independent of other User Stories, meaning they can be developed in any order
Negotiable Facilitate open conversation within the development team: changes to the User Story can be discussed and implemented
Valuable Bring value to user/stakeholder, adding overall value to the product
Estimable Able to be estimated using the sizing criteria discussed, e.g., T-Shirt sizing or Story Points, allowing prioritization and scheduling
Small Must be manageable enough to be developed in a single iteration, and not so detailed that ongoing conversation is redundant
Testable Should only be considered done once it meets agreed acceptance criteria that can be tested and validated
If your User Stories meet the INVEST criteria, then your team is set for success in its workflow management. ## User Story Benefits User Stories offer a great number of benefits to development teams: * Stories ensure the team remains focused on the benefits for the user and the business value, ultimately developing a better product that is not only well built technically, but also brings real value to real users. * User Stories encourage and facilitate collaboration. With the focus on a team-wide discussion rather than on lengthy, written explanations of requirements, the team is freed up to collaborate, drawing on one another’s strengths and expertise. \   * User Stories foster creativity. The team are encouraged to critically and creatively consider how to achieve the end goal. * Stories create momentum. The development team complete small, manageable tasks consistently as the User Stories pass through the workflow, offering a regular sense of achievement and creating pace.
Common Interview Questions ## What's a user story? Me: A short 📝 description that: ✍ As a user 👤 I want some features ✨ To achieve a goal 🎯 Interviewer: Can you give an example? Me: 👤As a user 📱 I want to bookmark articles 📖So that I can read them later ### Interviewer: What's the purpose of a user story? Me: A user story: 💁‍♀️Captures requirements from the user's 👤perspective 📏Estimates scope from the user's goal 🎯Guides development toward user value Interviewer: Why use AS/WANT/SO THAT format? Me: By specifying: ✅ The user 👤 ✅ The needed feature ✨ ✅ The benefit 📈 Development 👩‍💻focuses on: 🔹Delivering user value 🔹Satisfying the user's goal ### Interviewer: What makes a good user story? Me: It's: ✅Concise but descriptive ✅Focused on a single goal ✅Written in the user's voice Not technical jargon 🗣 or UI details ✍ Interviewer: Any final thoughts? Me: User stories help developers ☑️build the right things 🎯 by understanding the user's goal. They ensure features ✨align with real business needs 📈and create the most value📈. Simple yet powerful ⚡, effective user stories are key to Agile success 🏆! ### Interviewer: How do you estimate story points for testing? ✍️ Estimating testing efforts in Agile is always approximate 🧮 due to changing requirements 🔄 and dependencies 🤝. But some techniques that help are: 👥 Involve testers in planning and estimations ♻️Base estimates on past similar stories 🔢 Break down stories into tasks and estimate those ✏️ Write test cases before estimation 📝 Consider complexity, risk, edge cases, and non-functional aspects ➕ Add buffer for uncertainty ♻️ Adjust estimates as you gain more information To keep estimates useful 📏: 🔄 Update them frequently 📈 Track actual vs estimated effort ♻️ Adjust for the next Sprint 🧠 Learn from past inaccuracies Most importantly, use estimates to maximize value 📈, not for micromanaging 🙅‍♀️. As testers, focus more on prioritization, risk 📉 reduction, and delivering working tested software 👌.
## What are Story Points? 💡 **Story Points** are a relative measure of the effort and complexity required to implement a user story. They are used to estimate how much work can be completed in a sprint. ## Why Use Story Points Instead of Hours? ⏱️ Using abstract points instead of hours helps account for the **uncertainty** in estimating and the **varying capacities** of team members. ## How are Story Points Assigned? 📏 During sprint planning, the team plays **Planning Poker** 🃏 to estimate the size of each story using the Fibonacci sequence: * `1, 2, 3, 5, 8, 13, 20, 40, 100` The discussion and negotiation lead to consensus on the story point value. ## What Do Story Points Represent? 🤔 Story points represent the **overall effort** required to complete a user story. This includes: * Design * Development * Testing * Documentation The focus is on the total effort, not just development time. ## How Are Story Points Measured? 📈 Story points have no specific numeric value. They are relative units of measure: * A 5-point story requires five times as much effort as a 1-point story. * A 20-point story requires twice the effort of a 10-point story. ## What is Velocity? 🚀 **Velocity** represents the number of story points the team completes within a sprint. * Velocity = Total Story Points per Sprint Velocity helps the team forecast how much work they can complete in upcoming sprints. ## Key Takeaways 📝 * Story points are abstract, relative units of measure for estimating effort. * They account for uncertainty and varying team capacities. * Velocity represents the number of story points per sprint and helps with forecasting.