summary
Format and Basic Components of User Stories
The purpose of a user story is to provide a guide from business/product stakeholders to the development team to be able to develop a feature and to the QA team to develop test cases to ensure the feature has been developed successfully.
Summary Statement
for quick understanding of user story purpose.
Requirements
that the user story seeks to meet.
acceptance criteria
that would indicate whether a feature passes or fails, in terms of meeting the requirements of the user story.
User Story Templates
Learn More >
Frameworks and Best Practices for User Stories
Several frameworks and best practices exist for writing user stories. Borrow any of these for your local organizational context. Depending on your team’s size, requirements, and capacity, you might not need (or have the bandwidth) to follow all of the best practices. But using one or more are proven to increase delivery team efficiency by minimizing mistakes and eliminating ambiguity.
USER STORY SUMMARY
Provide Context for Your Feature
Provide context for your feature and user flow, ideally in the summary statement. Context helps your development team understand “for whom” and “for what” your feature is being built, so that they can develop the best “how.”
example: “As a [persona], I can [action] so that [intended result].”
Define the intended end user
This is the "persona" in the above example statement. The persona helps give perspective to the development team to understand who will be using the feature. Personas might include: website visitor, content managers, both external and internal users.
More in Guide to Defining Personas »
define the intended result
Defining the intended result helps give context to the end goal for the action. The goal is to avoid building out features in a silo, based on assumptions. Instead, the result is one of the criteria of successful implementation of the feature.
User Story Examples
Learn More >
USER STORY QUALITY
Follow INVEST
Follow the INVEST model for writing user stories. The INVEST mnemonic is a checklist of quality criteria that guides effective user stories.
Independent
Is your user story independent, or does it have big dependencies that may block its development? Try to make stories as independent as possible, to allow for true ability to prioritize the story backlog.
Negotiable
Does your story have flexibility in meeting the goal, or does it micromanage every interaction? Stories should allow for alternative solutions since multiple solutions may provide the same result.
Valuable
Does your story provide value to the customer? Defining value is essential to prioritizing the story backlog and navigating limited team capacity. Remember: value is not limited to monetary financials. Value could also include infrastructure stability, time efficiencies, or planning for the future.
Estimable
Is your story written to allow developers to estimate the level of effort? Stories need to be estimable to know how and when they fill within a product backlog.
Small
Is your story small enough to fit within one iteration? If not, the story likely has room to be split into several smaller stories. This allows for faster development and mitigates risk by making features bite-sized.
Testable
Is your story written in a way that provides the basic criteria to develop tests? Stories need to provide criteria for what a successful implementation looks like for the feature.
More examples of the INVEST method
Learn More >
USER STORY STRUCTURE
Apply Gherkin Method
Gherkin Method provides structure and format to user stories. It’s especially helpful when a story has multiple alternative flows, as it provides clarity.
Important terms:
- Given [Precondition or Initial Context]
- When [Action, Event, or Trigger]
- Then [Expected outcome]
- And
- But
"Given" defines context
example: "Given a website visitor is on any landing page"
"When" defines action or trigger within the Given context
example: "When the website visitor clicks on a link" (while on any landing page)
"Then" defines expected outcome
example: "Then the website visitor sees a new tab open" (for the link that was clicked)
Need more examples of Gherkin in practice? Check out the Learn More >
user story risk mitigation
Plan for Exceptions, Alternate Flows, and Unhappy Paths
In an ideal world, all users would follow the main path, often called the “happy path.” In reality, exceptions and “unhappy paths” do occur, and stories should include a plan for these.
identify places in the main flow when the user has more than one choice
Are there points in the flow where a user can perform multiple actions? Perhaps there's a form field. A happy flow could be that the user completes the field. An alternate flow could be that the user skips the field - what happens then? Another alternate flow could be that the user completes the field with nonsensical information - what happens then?
identify alternate flows or ways to drive the user back to the happy flow
When the possibility of an exception or alternate path opens, you can decide: should the feature allow for a separate new flow, or should the feature drive the user back to the original flow? Thinking about the form field, potentially the user could see error messaging and be blocked from proceeding. Alternatively, the user could be allowed to proceed. Decide based on your business context and requirements.
More examples of Alternate Flows and Edge Cases
Learn More >
