User Stories
Writing good User Stories is critical to the success of the project. Since a User Story describes a specific "output" that is desired, it is important that it contains all the necessary requirements. The basic requirements are categorized by what the output is, who will use it, and why they want to have it. In its traditional form, it would be written like this:
As a User, I want Output so that Reason.
User
Think of your whole project as creating some complete system. This complete system may have many parts, and there are often many types of people who will be interacting with the system. We call these people "Users" of the system. For example, if you were building software to run an online store, there may be users such as Visitors, Customers, Inventory Managers, Support Representative, Administrator, and many other possible users. Each user will have a different experience when interacting with the system. By identifying these specific types of users, we can better communicate about who will be the audience of a given experience.
Here's an example of a possible user story for a scenario like this:
As a Visitor, I want to see popular products early in my experience so that the chance of me finding an interesting product is increased.
This user story is targeted for the Visitor, which could be classified as someone who is likely not a returning customer. The user story about identifies this behavior should apply to the Visitor only. If we had another user type, such as a Customer, we may want their experience to start off with recommendations based on previous purchases. These are, of course, only suggestions, but should help to clarify how we can identify specific users of the system can have a different experience.
Here's an example of a possible user story for a scenario like this:
As a Visitor, I want to see popular products early in my experience so that the chance of me finding an interesting product is increased.
This user story is targeted for the Visitor, which could be classified as someone who is likely not a returning customer. The user story about identifies this behavior should apply to the Visitor only. If we had another user type, such as a Customer, we may want their experience to start off with recommendations based on previous purchases. These are, of course, only suggestions, but should help to clarify how we can identify specific users of the system can have a different experience.
Output
We also need to identify what experience the user should have. The output explains the "what" portion of the user story. In the above example, the user wants to "see popular products early in my experience." This describes a goal in a concise form, but certainly opens up for many questions to be asked to clarify what exactly would need to be done in order to meet this goal. That specific detail is commonly referred to as Acceptance Criteria, which is discussed in a different section. The purpose of this element of the user story is to highlight what is wanted from a goal perspective first, in terms of what it is a user wants, not how a user wants it. The Acceptance Criteria is much more specific about how a user would experience it, rather than just what they would experience.
Reason
There are a variety of reasons to include the "so that" portion of the user story sentence. While it may seem obvious to some members of the team that some outcome is desired, this assumption can lead to a problems.
It can serve as a double-check to make sure that a team is not wasting time doing work on something that isn't needed. If it cannot be determined "why" something is needed, then perhaps it isn't needed at all. The previous example seems to propose that by showing a popular product, it is more likely to be an interesting product to a new visitor. The basic assumption is that if a product is interesting to a majority of customers, and thus becomes popular, it is likely to be of interest to the new visitor. This seems fairly logical, so as a double-check, it could be decided that this backlog item has a valuable proposition.
The "so that" phase can influence "how" the user should experience the specific scenario. In the previous example, it describes the desire to help increase the chance of finding an interesting product. Perhaps this could influence how the products are sorted to ensure that the most popular product is seen first. When reviewing the Acceptance Criteria, it would be good to compare each point to the "so that" portion of the user story sentence to see if the particular requirement seems to support the initial desired reason.
It can serve as a double-check to make sure that a team is not wasting time doing work on something that isn't needed. If it cannot be determined "why" something is needed, then perhaps it isn't needed at all. The previous example seems to propose that by showing a popular product, it is more likely to be an interesting product to a new visitor. The basic assumption is that if a product is interesting to a majority of customers, and thus becomes popular, it is likely to be of interest to the new visitor. This seems fairly logical, so as a double-check, it could be decided that this backlog item has a valuable proposition.
The "so that" phase can influence "how" the user should experience the specific scenario. In the previous example, it describes the desire to help increase the chance of finding an interesting product. Perhaps this could influence how the products are sorted to ensure that the most popular product is seen first. When reviewing the Acceptance Criteria, it would be good to compare each point to the "so that" portion of the user story sentence to see if the particular requirement seems to support the initial desired reason.
Acceptance Criteria
The more clarity provided to the team, the higher the probability that the team will meet the expectations of the Product Owner. However, specifying too much may increase the time it takes to produce the desired output, so there needs to be some tradeoffs with regards to how specific the criteria is. A good recommendation is to leverage the "so that" phrase of the user story sentence as a double-check to make sure the criteria is needed in order to support the intended reason this work is being done. Generally, it is recommend to also keep the criteria only as technical as is needed.
A good way to identify what Acceptance Criteria is needed is to read the user story sentence and think about what questions it brings to mind. Here are some questions that may be reasonable given the previous example:
There could certainly be more questions raised after reading the user story and imagining how it would be experienced by the given user once it is completed. But by asking questions, it can help identify what criteria could be specified in the Backlog Item so that every one on the team is clear about what to expect. This criteria provides the Team Member some specifics about what they would build, and when they can reasonably determine that they are finished. It also helps the Product Owner to validate that the goal has been completed once the work is done.
Given the above questions, we may write the acceptance criteria as follows:
A product is popular based on most number of sales and most positive reviews.
The top 5 popular products, ordered by most positive reviews first.
Popular products should be shown as the first section of content on the home page.
Display product name, photo, price and average star ranking based on user reviews.
This is just an example of a level of clarity that could be attainted. It is good for all members of the team to review the user story to help determine what level of clarity is required.
A good way to identify what Acceptance Criteria is needed is to read the user story sentence and think about what questions it brings to mind. Here are some questions that may be reasonable given the previous example:
- What does it mean for a product to be popular?
- How many popular products should be shown?
- What does it mean to be early in the experience?
- What elements of a product should be seen?
There could certainly be more questions raised after reading the user story and imagining how it would be experienced by the given user once it is completed. But by asking questions, it can help identify what criteria could be specified in the Backlog Item so that every one on the team is clear about what to expect. This criteria provides the Team Member some specifics about what they would build, and when they can reasonably determine that they are finished. It also helps the Product Owner to validate that the goal has been completed once the work is done.
Given the above questions, we may write the acceptance criteria as follows:
A product is popular based on most number of sales and most positive reviews.
The top 5 popular products, ordered by most positive reviews first.
Popular products should be shown as the first section of content on the home page.
Display product name, photo, price and average star ranking based on user reviews.
This is just an example of a level of clarity that could be attainted. It is good for all members of the team to review the user story to help determine what level of clarity is required.