A user story is a short, simple and natural language description of one or more functionality. User Stories are written from the perspective of the person who desires a new capability to achieve something through a product or service.

A User Story is not a contract of what needs to be implement in the solution. It’s an invitation to a conversation. The story captures the essence of what is wanted and why. The actual solution is delivered as a result of collaborative negotiation between the User (or user proxy like the Product Owner/Product Manager) and the team. For more about user stories please see: INVEST User Stories.

Not all product backlog items require a user story format. For alternative formats, please see the guide on Other Product Backlog Items

Recommended User Story Format

• User Story (What/Why):
  • Use the “As a… I want… so that…” format to capture the user’s need and desired outcome.
  • Example: As a Customer, I want to search for products by category so that I can easily find what I’m looking for.
• Description/Context (Why/What):
  • Briefly explain the purpose and context of the user story.
• Design Notes (What/How):
  • Outline any high-level design considerations for the user story.
• Tech Notes (How):
  • Briefly describe the technical aspects involved in implementing the user story.
• Test & QA Notes (How):
  • Specify any testing or quality assurance considerations.
• Acceptance Criteria (What):
  • Define detailed requirements for the product manager or product owner to sign off on. These criteria should clearly indicate when the user story is considered complete.
  • Use the Given-When-Then format (explained below) for clear acceptance criteria.
    • Recommended Acceptance Criteria Format:
      • Given (a precondition) AND (some more preconditions)
        • This describes the initial state or setup required for the test.
      • When (an action by user) AND (some other actions)
        • This outlines the user’s specific actions.
      • Then (some testable outcome is achieved) AND (something else we can check happens too)
        • This defines the expected results of the user’s actions.
• NFRs/Other Considerations (What):
  • Identify any Non-Functional Requirements (NFRs) or other relevant considerations for the user story.