User Story Template - Free Download & Writing Guide

User stories form the backbone of every agile project and translate user needs into concrete development tasks. A well-written user story communicates not only what needs to be built but also why it is valuable to the user. This template helps you write effective user stories following the standard "As a [role], I want to [action], so that [value]" format. It includes sections for acceptance criteria in Given-When-Then format, story points based on complexity, priority classification, dependencies with other stories or systems, technical notes for the development team and a Definition of Ready checklist. By consistently documenting user stories you create a shared understanding between product owner, developers and testers about what needs to be built. The template also includes tips for splitting oversized stories (epics) into smaller, sprint-ready stories that meet the INVEST principle. Additionally, it provides a section for linking user stories to personas and user journeys, so the team always understands the broader context within which an individual story delivers value to the end user. It also includes guidelines for writing non-functional stories that capture performance requirements, security criteria and scalability needs in a format the team can immediately pick up and test.

Variations

How to use

Step 1: Download the user story template and open it in your project management tool or text editor. Make it part of your backlog refinement process so stories are documented consistently. Step 2: Identify the user role that benefits from the feature and fill in the "As a [role]" portion. Be specific: "As a logged-in customer" is better than "As a user". Use personas if available. Step 3: Describe the desired action from the user perspective in the "I want to [action]" portion. Focus on the goal, not the implementation. "I want to filter my orders by date" is better than "I want a date filter component". Step 4: Formulate the business value or goal in the "so that [value]" portion. This helps the team understand why the feature matters and makes it possible to prioritise based on value. Step 5: Write acceptance criteria in Given-When-Then format. Each criterion describes a testable scenario: "Given I am logged in and have three orders, when I filter by last month, then I see only the order from last week." Aim for three to seven criteria per story. Step 6: Estimate complexity with story points via planning poker with the team. Use the Fibonacci sequence (1, 2, 3, 5, 8, 13) and compare with reference stories. Stories larger than eight points are candidates for splitting. Step 7: Set priority based on business value, urgency and dependencies. Use the MoSCoW method as a supplement to the backlog ordering by the product owner. Step 8: Note any dependencies on other stories, external systems, datasets or team members. Step 9: Add technical notes relevant to the development team: API endpoints, database changes or design references. Step 10: Check whether the story meets the Definition of Ready checklist before including it in a sprint: is the description clear, are acceptance criteria testable, has the estimate been done and have dependencies been identified? Step 11: Link the user story to the relevant persona and the point in the user journey where this feature belongs. This helps the team understand the context and make design decisions consistent with the broader user experience. Also note which metrics indicate whether the story is successful after delivery, such as usage frequency or customer satisfaction scores. Step 12: After the story is delivered, evaluate whether the acceptance criteria are fully covered by automated tests. Flag stories that still require manual verification and schedule them as regression test candidates for future sprints, so you build a growing library of validated user stories that serves as living documentation for the product. Step 13: Run periodic backlog grooming sessions where you reassess existing user stories for relevance and currency. Remove stories that are no longer needed, split stories that have grown too large and rewrite stories whose context has changed. This keeps the backlog manageable and relevant. Step 14: Attach test scenario definitions to each user story specifying which scenarios the tester must verify for acceptance. By doing this when writing the story you prevent the test team from having to guess what exactly needs to be validated later.

How MG Software can help

At MG Software we train product owners and development teams in writing effective user stories. Our agile coaches facilitate backlog refinement sessions, help split epics into sprint-ready stories and ensure acceptance criteria are testable and unambiguous. We bring best practices from dozens of projects and adapt them to your specific context. The result: a well-maintained backlog with stories the team can pick up immediately, leading to shorter sprint planning sessions and delivered software that better meets stakeholder expectations. Our approach goes beyond just writing stories: we help teams run story mapping workshops where the full user journey is visualised and translated into a prioritised backlog. We also implement a Definition of Ready that acts as a quality gate before stories enter a sprint, so the team is no longer surprised by unclear or incomplete requirements during development. For technical teams we offer specific guidance on formulating non-functional stories for performance, security and technical debt, including measurable acceptance criteria that can be objectively verified through automated testing or monitoring thresholds.