Best Practices for Writing User Stories for Sitecore Projects

User Stories Foster a Shared Understanding

Crafting quality user stories is considered to be a desired skill in the world of agile product management. These stories bridge the gap between developers and client stakeholders by clearly outlining the details of the features to be build. It helps foster a shared understanding of the product and its features because user stories are written from the perspective of the end user.

This blog post covers the best practices and considerations to be taken into account when writing effective user stories that benefits both the developers and the client stakeholders. We are going to take a deeper dive into how user stories are integral for the smooth delivery of any project and will also take a look at, particularly for Sitecore projects.

What is a User Story?

User experience for any product should be the main focus. Products are build for users and enhancing the experience for the end user, increases the likelihood for a product’s adoption with the masses. Often times there is a huge gap in better understanding and eventually delivering the desired value for any product. This is where a user story helps to bridge that understanding gap and help the technical teams build a product which the user actually wants. Let’s break it down and explore more into what a user story is and why is it important.

A product has various features and each product feature delivers portion of the value that the product is expected to do. In an agile environment, there is a client stakeholder who is the owner of the product and explains to the technical teams exactly what a feature of the product is supposed to do. This is the starting point for this understanding gap to take place and broaden. The client stakeholder explains the product feature from the perspective of adding value to the product whereas the technical team starts thinking from the mindset of technical feasibility and answering the how of the development process. Questions like these often arise:

• What should be the architecture for this?
• How should this be built?
• What are the considerations to look at from the technology side of things?

These are all valid questions and necessary to focus on when developing the feature. However, the gap remains because from both standpoints, we didn’t really look at from the perspective of the end user. At this point, writing detailed user stories can be extremely essential.

A user story describes the value of any product feature with the end user as the main subject and the main character of the story. The story is written as the first person narrative with the user being the person explaining how the product feature is going to be beneficial and increasing the value and the user experience.

Best Practices for Writing User Stories

Let’s take a look at some of the industry best practices in writing exceptional user stories.

Present a Narrative as a First Person

The user story should always be written as a first person with the focus being on the end user. The core questions to ask before starting a user story should be:

• Role: Who is the user?
• Action: What do they want to do?
• Benefit: Why do they want to do it?

The answers to these questions can then be combined in a simple standard format that forms the basis of the details to follow for any user story. The user story narrative is written as:

“As a [ROLE], I want to [ACTION], so that I can [BENEFIT].”

where,

• role is the user role for whom the product is created or for the user who will be involved in some capacity in using the product. For example, a user can be an online shopper or an office manager.
• action is intended behavior of the user with the product. It refers to how the user is going to interact with the product. For instance, an online shopper would want to click on the displayed filter button to narrow down the number of product categories being searched for.
• benefit is the outcome or value being gained by the user. What advantage or merit does the user get by interacting with the product in that certain way. For example, the office manager is better able to view the reports in a user friendly dashboard.

Beginning a user story with this description, before any further details, is a great starting point for building the road towards effective communication and shared understanding between all the parties involved in the development phase of the product.

Be Descriptive, Specific and Yet Concise

Any story is meant to spark an emotion, interest and curiosity. This is exactly what a user story is suppose to deliver. Initiate an interest into the feature of the product for which the user story is focused on. It should contain all the relevant details to be communicated to the developers so that the team can really understand what the value is being generated for the users by working on this specific feature. The user story should be to the point, covering all the different use cases, applications and associated details of the feature. While writing user stories, it should always be kept in mind, that even though it should be descriptive but it should never be ambiguous for the developers. It should be to the point and effectively and easily communicate the needed details for the developers to begin working on the user story.

Include All Requirements

The user story should include all the requirements associated with the feature. This includes the details around the expected functionality and behavior of the feature, details for any backend logic involved and how is it suppose to be functioning and any details around any expectations of the end users.

Requirements should also include specific needs for the people who would be involved in the day to day management of the product and will have some specific needs for the features which are being built. A user story should outline details around all these needs and requirements for all the different stakeholders who will be involved in any capacity to interact with the product. Even though, they might not be the end users but still are the users of the product and will be engaging with it in some shape or form.

Detailed Acceptance Criteria

Acceptance criteria is an essential component of any user story. This can be thought of as a checklist of verification to decide if the feature built is a pass or a fail. This is extremely helpful during the QA process where a tester can go through each listed acceptance criteria and verify if the product feature is complying with that or not.

The acceptance criteria should be very detailed covering all the different scenarios and examining the product feature from the various perspectives, in terms of its behavior and functionality. For instance, it should cover information around the responsive behavior of a web component, details around meeting the accessibility requirements and any other necessary details that would qualify the product as a success.

Tailoring User Stories for Sitecore

When writing user stories for Sitecore projects, it is important to adapt them to the platform’s capabilities and functionalities. You should always begin by clearly identifying the user persona who will be involved in engaging with the product feature. It could be either a content author, marketer, developer or the website user. For example, a story for a content author would focus on the ability to intuitively delivering targeted content and crafting a seamless user experience for the user.

A Sitecore user story should also include relevant information that might be helpful for the developers. For instance, details of any existing component fields and IDs that could be used in architecting the solution.

Common Mistakes in Writing User Stories and How to Avoid Them

Writing user stories for Sitecore projects can be challenging, and several common mistakes can hinder project success. One frequent error is writing user stories that are too vague or broad, which can lead to misunderstandings and scope creep. To avoid this, ensure each user story is specific and actionable, with clear and concise descriptions of the user's needs and the desired outcome. Incorporating well thought out acceptance criteria can also help in providing clarity..

Another common mistake is neglecting the user's perspective. User stories should always be written from the end-user's point of view, focusing on their goals and the value they seek. Avoid technical jargon and overly complex language that can be difficult for non-technical stakeholders to understand. Instead, use simple, user-centric language that clearly communicates the user's needs.

Additionally, it's crucial to prioritize user stories effectively, considering the business value and impact on the user experience. Regularly reviewing and refining user stories with the team and stakeholders can help foster and maintain shared understanding and ensure that the stories remain relevant and valuable throughout the project lifecycle.

Great User Stories Can Drives a Project’s Success

Properly crafted effective user stories forms the pillars to drive the success of any project. This practice promotes collaboration between various teams and stakeholders, clear communication, and a common understanding towards a shared goal. With perspective to any Sitecore projects, user stories provides a strong basis for developers to keep the different user needs in mind for everyone who will be involved with the product. Either a content author, manager, end-user or even the developer as well. The goal here is to enhance the quality of the product through clear communication and generation of value for the users.

Applying these best practices, as outlined in this blog post, and avoiding any common mistakes and pitfalls, can ensure a successful project delivery with a greater likelihood for success in users’ adoption for the product.

---