Product Management — User Stories

As a Product Manager/Product Owner, the bread and butter of your job is to properly guide the development team with features/functionalities you are planning to add to your product and remember the context in which they are designing.

In agile software development, user stories are specifically written from an end-user perspective, describing the type of user, what they want, and why they want it.

In an effort to keep user stories simple and clear, they are often written on index cards or post-it notes, paring down excessive documentation to an essential, customer-centric framework however mostly in Tech companies we use tools such as JIRA, VersionOne, etc.

The Anatomy of a User Story

There are two essential parts to a user story — a feature and a set of acceptance criteria. If the story involves a user interface, it also needs to list the UX/UI artifacts.

The Feature

The feature represents the product increment. It should be written in this format: “As a <who>, I need to <what> so that <why>.”

For example: “As an online customer, I need to search for products, so that I can find the ones I want to buy.”

This short sentence alone conveys three key pieces of information:

• Who cares about this feature? (the shopper)
• What do they want? (to search products)
• Why do they want it? (so they can buy some)

The Acceptance Criteria

The acceptance criteria should cover all the nuances that must be built into the product in order to implement the feature. While the feature is written from the user’s point of view, the acceptance criteria is written from the product’s point of view.

Referring back to the above example: “As an online customer, I need to search for products, so that I can find the ones I want to buy,” you might list acceptance criteria like:

1. Search for a product by name or category
2. View products by category
3. View images and details for each product
4. Add to cart from the detail or search pages

The UX/UI Artifacts

The UX/UI designs built for the story need to be listed in each story as part of story elaboration.

Types of User Stories

Once a PM/PO is able to recognize the type of story needed, it becomes easier for them to focus on the criteria that are important for the story acceptance.

Behavior-Driven Stories

These are stories where the user’s actions or decisions are the focus. These stories typically have a number of scenarios to be considered.

For example: “As a customer, I need to authenticate myself so that I can see my account details and past orders.”

In this example, there are multiple possible scenarios:

1. User entered the correct credentials for authentication
2. User entered incorrect credentials for authentication
3. User realizes that they forgot the credentials
4. User realizes that they do not have an account, and wants to create one now

For each scenario, we need the acceptance criteria defined.

Rules-Driven Stories

There are also stories where the focus needs to be on the business rules. The user actions do not have much relevance within the scope of the story (there could be related stories where the user action is in focus).

For example: “As a customer searching for a product, I need to be presented the most appropriate choices, so that I am likely to find what I am looking for.”

This story is about the business rules to be built to support search. There would be other stories to cover the user behavior around using the ‘search’ function.

Thus, the acceptance criteria for this story would look like:

For finding the products that match the search criteria, use the following attributes in the order listed below.

• Product name
• Product variation name
• Product short description
• Product long description
• Product reviews

Content-Driven Stories

These are stories that revolve around the content generation and display.

The content-driven stories are a hybrid between behavior-driven and rules-driven stories. They do have a behavior aspect, but the rules behind the content generation/display are often more complex than the user behavior itself.

Here is an example: “As a customer, I need to be informed of the benefits of the loyalty program so that I benefit from the program.”

Acceptance criteria:

1) The loyalty program benefits need to be displayed as a banner over the header.

2) It should be possible to configure via the administration console the date range during which this banner needs to be displayed.

• The user should be mandated to enter both the ‘from’ and ‘to’ dates for the date range.
• The banner should automatically appear and disappear according to the date range.

3) It should be possible to configure the banner such that it is personalized for each user. The following four user segments should be available for this configuration.

• Anonymous user
• Signed-in user who is not a loyalty program member
• Signed-in user who is a loyalty program member but has no loyalty points
• Signed-in user who is a loyalty program member and has at least one loyalty point

4) Set up the banner with the following images and links.

• Anonymous user — <image link> — link to “registration page”
• Signed-in user who is not a loyalty program member — <image link> — link to “profile page”
• Signed-in user who is a loyalty program member but has no loyalty points — <image link> — no link
• Signed-in user who is a loyalty program member and has at least one loyalty point — <image link> — no link

6) When the banner has not been configured (correctly) for a specific user segment, then do not display the banner for those users.

Improvement Stories

There are often situations where we need to make a small improvement over a story that has already been built.

Here is an example. Let’s say we had a site where all the error messages on the registration page were in ‘black’ color. After getting some real customer feedback, it was understood that the error messages need to be in a ‘red’ color for them to be noticed. So we would have a story that goes as follows.

“As a customer trying to register for an account, I need to be informed clearly if I am making any errors, so that I can fix them quickly.”

Now there is no point in writing a detailed acceptance criteria covering all error scenarios. This must have already been covered in the story/stories that were built. So, simple acceptance criteria is all that is needed in this case.

Acceptance criteria:

• Change the font color of all error messages in registration page to ‘red’ for all error scenarios. Refer to story <provide link> for the list of error scenarios.

Integration Stories

When building a product backlog, there will be a need to write stories that result in technical integration work. For example, between eCommerce store and OMS (order management system), or between eCommerce store and a payment gateway.

Figuring out the technical details of the integration is outside the purview of the story definition. However, the story needs to define sufficient scenarios to drive the downstream technical analysis.

The granularity of a Story

The first rule: The story needs to represent a meaningful product increment to the product user.

The second rule: The story needs to be small enough for the team to implement in one sprint (practically it breaches though ;)).