Select Page

Writing User Stories 

A user story is a tool used in software development to capture a description of a feature or functionality from the end user’s perspective.  The purpose of a user story is to ensure that the development team is aligned with the needs and expectations of the end-user and that the resulting software product will meet the user’s requirements. By focusing on the user’s perspective, the development team can better understand the problem that the user is trying to solve and create a solution tailored to their needs.

User stories follow a simple template. 

Note: When referencing a type of user, it’s best practice to reference the persona(s) to which the story refers to; this provides additional context to the engineering team. Where possible, link to the persona documentation for new team members. 

Title:

User Story:

As a {type of user}

I want to {perform some task}

so that I can {achieve a goal}

Acceptance Criteria:

Given that {some context}, 

when {some actions is carried out}

then {a set of observable outcomes should occur}

While user stories at their basic level are simple, additional details can be added to provide additional context to the engineering team as well as additional considerations. 

Additional Details:

  • Background (optional): Examples include why you are prioritising this feature/enhancement, will it drive sales, reduce customer churn or is it to match a competitor?
  • Assumption: What assumptions are you making?
  • Acceptance Criteria: What are the expectations that the story must meet, i.e. results should be returned within less than 5 seconds? 
  • Link to UI/UX Designs: A link to UI/UX designs. 
  • Testing Touch Points: If you’re making changes to certain areas of the application, what areas which might be affected also need testing? 
  • Flowchart: How does this feature fit into the larger workflow of the users?
  • Out Of Scope: 
  • Customer Scenarios: Describe how customers are expected to use the new feature as part of their larger workflow, which can be used for testing. 
  • Blockers (linked stories): What other stories must be completed before this story can be implemented? 
  • Dependencies: What are the dependencies that need to be addressed before the story can be implemented, i.e. do you need I.T to make an infrastructure change or need to purchase a software licence? 
  • Known Issue: What are some known issues that may come up in testing? 

Considerations:

  • Security Audit Required: Are you making changes to an area of the application which might require an additional security audit? 
  • Legal: Do you need sign-off from legal for:
    • Using a new open-source library?
    • Are any new product names copyrighted?
    • Do your terms and conditions/EULA need to be updated?
    • Do you need to update your cyber insurance? 
  • Documentation Update:
  • Test Data: What test data do you need to enable both the development and testing teams?
  • Hardware: Is additional hardware required to implement or test this story, i.e. a 2FA token?
  • Software Licences: Do you require additional software licences to support this new feature?
  • Partnership Agreements: What partnership agreements might be beneficial to support the story?
  • System Requirements: Does this new feature need to be able to run in old web browsers or on old operating systems?

      Reviewed By:

      • Product Manager
      • Product Owner
      • Architect
      • Dev Manager
      • Principle
      • Design

      Informed:

      • Performance
      • IT
      • DevOps
      • Security