Developing user stories - or an informal, natural description of your customer’s potential online journey - can help guide the development of your user experience, product management, web design, and more.
If you’re an eCommerce company, then you have “users,” or customers, who use your website to purchase products.
Developing user stories - or an informal, natural description of your customer’s potential online journey - can help guide the development of your user experience, product management, web design, and more.
User stories that are written properly guide the functionality of your online store, and help development team members 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.
This story card style writing is incredibly helpful because let’s face it: how often do your teams read a complex, long, technical requirements document? User stories cut through the density while still providing essential communication to teams responsible for designing and implementing user-focused systems.
Particularly in agile practices in, like Scrum, user stories cut down on miscommunications (and associated costs), and allow for rapid delivery and sudden change.
Consequently, they ensure delivery of rapidly-developed, cost-effective, and customer-centric experiences.
As we’ve already discussed, agile user stories are short and sweet.
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.
These three pieces are the standard parts of a story, though the Product Owner can add more information if needed.
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:
Here’s another example: “As a customer looking at a product, I need to be informed if a product is on sale, so that I am encouraged to purchase it.”
In these scenarios, the user is the user of the “product,” or the eCommerce store. It is recommended to add a “context” in addition to the “user” to complete the “who.” This makes the feature more meaningful.
For example: “As a customer looking at a product, I need to be informed if a product is on sale, so that I am encouraged to purchase it” is more meaningful than “As a customer, I need to be informed if a product is on sale, so that I am encouraged to purchase it.”
While the “who” is an important part of the feature, the “what” might be the most important part of all. That’s because this is what gets built in the product. The acceptance criteria in a story needs to be aligned to this “what.”
The “why” helps the team recognize why they are building a specific feature. The “why” is what ties the story back to the vision for the product.
The acceptance criteria should cover all the nuances that must be built in 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:
It is important to clearly number each acceptance criteria. This makes it easier to reference during refinement, demos, and acceptance testing.
Also, the acceptance criteria should be kept as generic as possible when it comes to referring to any specific UI element. For example, rather than using specific terms such as “link” or “button” use a more generic term such as “CTA” (call to action). If possible avoid device-specific terms such as “click” and “tap.”
The UX/UI designs built for the story need to be listed in each story as part of story elaboration.
List the artifacts for various devices separately (ex. desktop, mobile, tablet). It is also recommended to insert small/relevant snippets of UI within the acceptance criteria. If it is a complex UI, you could also have screenshots with numbers/labels and reference them within the acceptance criteria.
There are five different kinds of user stories that we typically encounter:
Once a Product Owner 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.
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:
For each scenario, we need the acceptance criteria defined. Use simple language in an active voice to state what the product needs to do. Each scenario is expected to have a “WHEN” and a “THEN” phrase. If the scenario is dependent on a specific pre-condition, then the scenario would need a “GIVEN” phrase too.
GIVEN <situational pre-condition>
WHEN <user action 1> and <user action 2> and … <user action n>
THEN <product action 1> and <product action 2> and … <product action n>
The earlier user story now would look as follows: “As a customer, I need to authenticate myself so that I can see my account details and past orders.”
Acceptance criteria:
When the user enters the correct email address and password and selects “sign-in” CTA
Then route the user to My Account home page and display signed-in status on header
When the user enters an incorrect combination of email address and password and selects “sign-in” CTA
Then reset credentials fields and display an error message “Incorrect Credentials”
When the user selects the “forgot credentials” CTA
Then route the user to the “forgot credentials” page
When the user selects the “register” CTA
Then route the user to the “registration” page
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:
1) For finding the products that match the search criteria, use the following attributes in the order listed below.
2) For finding the categories that match the search criteria, use the following attributes in the order listed below.
3) Both full and partial match should be attempted.
4) For a partial match, at least 3 characters should match.
5) Ignore all standard stop words while attempting a match.
6) Use synonyms to find a match. Refer to <link> for the list of synonyms.
7) A minimum of 3 characters needs to be entered to find a match.
These are stories that revolve around 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.
So, a rules-driven format is more suitable than a behavior-driven format for the acceptance criteria. How it differs from a rules-driven story is that the acceptance criteria, in this case, will need to refer to several snippets from the design pages and/or copy documents for it to be complete.
Keep in mind that the need for many of these stories are likely to come up only when UX/UI discussions happen. So it’s quite possible that none of these stories show up when the Product Owner does the first round of user story mapping with the product stakeholders.
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.”
1) The loyalty program benefits needs 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.
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.
4) For each user segment, it should be possible to configure the image and the link upon clicking the image.
5) Set up the banner with the following images and links.
6) When the banner has not been configured (correctly) for a specific user segment, then do not display the banner for those users.
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 ‘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:
When building a product backlog, there will be a need to write stories that result in a 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.
Here are a couple of examples. You will notice that in one case the format is of a behavior-driven story, and in the other the rules-driven format has been used. If the integration is of a request-response nature, a behavior-driven format works best. If the integration is of an offline mode, a rules-driven format works best.
Example 1) Credit card authorization: “As a customer about to make a purchase, I need to be able to submit my credit card details and get authorization so that I can complete my checkout.”
Acceptance criteria:
When the user enters the credit-card-number, year-and-month-of-expiry and cvv and selects “sign-in” CTA and authorization is successful
Then display “payment confirmation” message and persist authorization token for future reference (i.e, for sending for settlement)
When the user enters incorrect credit-card-number or year-and-month-of-expiry or cvv and selects “sign-in” CTA and authorization fails
Then display “payment failed” error-message and reset the payment fields
When the user enters the correct credit-card-number, year-and-month-of-expiry, cvv of a card with insufficient balance and selects “sign-in” CTA and authorization fails
Then display “payment failed” error-message and reset the payment fields
When the user enters the credit-card-number, year-and-month-of-expiry, cvv and selects “sign-in” CTA and authorization fails due to suspected fraud
Then display “error page” and keep the order on hold for ‘suspected fraud’
When the user enters the credit-card-number, year-and-month-of-expiry, cvv and selects “sign-in” CTA and connection to payment gateway fails
Then display “call customer service” message and reset the payment fields
Example 2) Order submission for fulfillment: “As a customer who made a purchase, I need to get my order fulfilled correctly in a timely manner so that I don’t have to follow-up via customer service.”
1) Send order details to the fulfillment system within 30 minutes of customer completing the checkout process
2) Send all required data so that picking, packing, settlement and shipping can happen for all order scenarios. Consider the following order scenarios:
Regardless of the type of story that is being written, there are two rules that govern the granularity of a story.
The first rule: The story needs to represent a meaningful product increment to the product user.
For example, if we are building a registration page, having two stories - one to display the form, and another to submit the form doesn’t make sense. Each individual story in this case doesn’t make any sense to the product user. We need a single story that can display the form and accept form submission. If there are any optional independent sections on the form (say a loyalty registration section), we could have a separate story to cover just that.
The second rule: The story needs to be small enough for the team to implement in one sprint.
A story may need to be split into multiple stories depending on the team’s experience and sprint duration. It’s perfectly fine to wait until refinement or planning with the team before doing this splitting.
It seems obvious, but it’s worth stating: a story needs to be easily readable.
Here are some tips:
Finally, a team may often need to perform multiple activities as part of realizing a story. Some common examples are the following:
These are tasks and not user stories. Therefore they do not need to follow user story guidelines. Rather, the team is expected to come up with the list of tasks required for a story during planning.
The finer points of writing user stories can at first seem overwhelming, but with practice, this agile project mentality becomes easier to grasp. Additionally, user story templates can help you if you’re first starting out.
And most significantly, the benefits outweigh the learning curve.
User stories not only allow you to rapidly, concisely, and clearly communicate a product’s requirements, but they deliver this information in a format that digestible for team members.
If you’re still not sure where to begin, contact our team of experts at Object Edge for more information or to set up a free call. We’re here to help.
