User Stories

The starting point for any features

What are User Stories?

Stories are the starting point for features that are built and are usually created by the product manager. It is a task that usually represents a feature from a user perspective. They are rarely technical or too prescriptive at the beginning, with tasks forming the bulk of the technical details.

Examples being:

• Add a product to cart

• Sign up for an account

• Logout of an account

• Create a post on a forum

• Submit a form

One story can spin off multiple tasks that, when done together, will allow for the user story to be completed.

Where do Stories Come From?

A PM can generate a large number of stories in one sitting to populate the backlog. They can come from:

• User research

• Customer feedback

• Taken from designs/mock ups created by UI/UX designers

A backlog can consist of many user stories that will be groomed regularly by the PM.

Ticket Template

Background

The context behind the feature/story. It can bring up the overall platform/app that the feature is to be a part of and why this feature is important. For example, why we need a feature to allow users to sign up for accounts on an e-commerce app

User Story

As a [description of user], I want [functionality] so that [benefit].

I won't go into too much detail as most of what I used as a PM for user stories can be found here:

https://www.productplan.com/glossary/user-story/

Key Points

This is usually where I put in some detail that isn't captured in the user story or background. For example:

• Links to product/user research

• Link to PRD

• Link to design

• Additional context

Acceptance Criteria

Acceptance criteria are used to guide developers, designers and QA towards your vision for this feature. It is important to be as specific and exhaustive as possible so that all edge cases are considered when designing, developing and testing the feature.

Given [list of prerequisites], when [action to trigger the feature], then [expected outcomes/actions/feedback]

For the action to trigger the feature, try to keep it to one specific action that triggers the feature instead of multiple actions. For example:

• Use: "When the button is clicked"

• Don't use: "When the button is clicked and you are logged in"

This reduces the amount of confusion around what actually causes the newly developed feature to execute or occur.

There are many ways to structure acceptance criteria. You can refer to this resource when structuring or designing acceptance crtieria:

https://www.productplan.com/glossary/acceptance-criteria/