11 minute read

Unlocking the potential of user stories for success in Salesforce

Home » Blog » Unlocking the potential of user stories for success in Salesforce
Home » Blog » Unlocking the potential of user stories for success in Salesforce

What are user stories?

In this article, we’ll be delving into Salesforce user stories. A User Story is a structured statement that outlines the work you need to complete, to meet the overall business requirement: “as a [role], I want to [action], so that I can [outcome].” A User Story articulates what an end user wants to achieve and why, breaking down potentially complex functionality into manageable and understandable pieces.

The user story is the critical handover document from the business to the development teams. Therefore it’s important that is unambiguous, easily understood, but also includes links back to the supporting information, to give it context.

Creating effective Salesforce user stories

Step 1: Understand the stakeholders and their needs

In crafting effective Salesforce user stories, the important initial step is to gain a thorough understanding of the stakeholders and their genuine needs. A common pitfall in this process is the confusion of ‘wants,’ with ‘needs.’ To discern the fundamental needs of the stakeholders, I employ the ‘5 Whys’ technique — repeatedly asking “why,” five times, to drill down to the core issue at hand. 

This probing is essential, because it peels away the layers of superficial wants, revealing the underlying need. Grasping this problem simplifies the entire process; it provides clarity on what exactly needs to be built within Salesforce. By doing so, it ensures that the implementation phase is firmly aligned with solving real problems, rather than being distracted by surface-level desires. 

This approach not only streamlines development, but also ensures that the solution is properly tailored to address the stakeholder challenges, within the Salesforce Org. 

Diagram showing the five whys technique for user stories: Define the problem: Why is it happening
?Why is that?Why is that?Why is that? Why is that?

Step 2: Define business requirements

Defining business requirements is a crucial step in any Salesforce implementation. These requirements, serve as a bridge between the capability model (the capability the change is affecting) and the necessary changes to meet stakeholder needs. It’s important to understand that business requirements, extend beyond system alterations; they can also relate to changes in operational processes. These requirements can be articulated at various levels.

There are two types of requirements: strategic and tactical.

Strategically, a business requirement might state the need for a revamped CPQ system to integrate a new AI product. On a more tactical level, it could involve the creation of support for a new opportunity type.

Essentially, the business requirement is the segment where stakeholder needs are thoroughly documented, detailing precisely what is needed and suggesting potential implementation methods aligned with the business capability that is undergoing change.

Salesforce user stories - image of a Capability model in Elements.cloud showing business capabilities connected to requirements
Capability model in Elements.cloud showing business capabilities connected to requirements

Step 3: Create an end-to-end UPN diagram

Once you have identified your stakeholder’s needs and documented them in a business requirement, it’s time to start understanding the impact of your change across the business.

Crafting an End-to-End (E2E) Universal Process Notation (UPN) diagram, is not just a formality. This is where you start to gather the intelligence of your Salesforce changes. This vital step brings clarity to the ‘why,’ ‘what’ and ‘who,’ behind every process improvement. This approach doesn’t just map out the change, it allows you to dive into the operational, regulatory, and technical nuances, revealing the full spectrum of the change’s impact. 

The E2E diagram is where you attach the human element (the personas) to each activity, grounding the changes in user experiences. Whether crafted manually or with AI-powered tools, the E2E UPN diagram serves as a blueprint, enabling the creation of user stories that detailed and informed, with clear inputs, activities, outputs and resources. In doing so, it ensures that the stories are not just narratives, but strategic tools that engage and align all stakeholders and developers, with the envisioned change.

An end-to-end diagram of a user story
End-to-End diagram mapped in Elements.cloud from where User Stories are born

Step 4: Develop persona-based user stories (using AI)

Persona-based end-user stories are a powerful technique in software development, particularly within the framework of Agile methodologies. Here are some of the key advantages:

  • Improved understanding of user needs: Personas are detailed descriptions of fictional users, that represent different user types. By crafting stories based on these personas, the development team can gain a deeper understanding of the users’ needs, experiences, emotions and goals.
  • Enhanced user focus: These stories help to maintain a strong focus on the user, throughout the development process. This user-centric approach, ensures that the Salesforce features are developed keeping the end user in mind, rather than being based solely on technical or business requirements.
  • Facilitates communication: Persona-based stories, provide a common language for stakeholders (including developers, designers and business personnel) to discuss and prioritize features. It’s easier to discuss what ‘Persona A’ might need, rather than abstract users.
  • More effective testing: Testing scenarios can be designed around persona-based stories, ensuring that the implementation is tested from the perspective of its end users. This can lead to the identification of potential issues that might not have been discovered otherwise.
  • Strategic business alignment: These stories help ensure that the business strategy is aligned with user needs, which can lead to higher adoption rates.
  • AI generated User Stories: AI can do an amazing job at building complete user stories directly from the UPN map. This saves a lot of time but also improves the accuracy of the user stories.
A diagram of a persona based user story
Example of a persona-based user story in Elements.cloud

Step 5: Document stories with metadata items

When the user stories are written, it is crucial to turn our attention to the associated metadata, which comprises elements that need to be created, updated, or sometimes removed. At this stage, performing an impact analysis on the metadata and documenting this within the user story becomes imperative. It is also vital to examine any dependencies the metadata might have. Identifying whether related components require updating and documenting these within the user story, can uncover potential risks and provide a clearer timeline for the changes. 

Such a detailed approach, facilitates clear communication with stakeholders and developers about the expected changes. The end product is a comprehensive change manifest, documented within the user story. Although user stories can be developed from the metadata, it is recommended to generate them from an end-to-end diagram to ensure a more contextual understanding of the changes required.

Stories documented in the right-hand panel from the E2E diagram
Documented metadata against the story from within the Elements.cloud application
Metadata dependency tree showing the documented story in the Elements.cloud right panel

Tips for writing high-quality Salesforce user stories

Writing high-quality Salesforce user stories, is crucial for ensuring that the development process, aligns with both operational and technical goals. Begin by establishing each story, as well-documented business processes. This ensures that the story not only reflects the needs and goals of the business, but also integrates seamlessly into the existing workflow and technical infrastructure.

Keep to standard format

Adhere to the tried-and-true structure: “as a [role], I want to [action], so that I can [outcome].” This format keeps the user story focused and actionable. For instance, “as a Product Manager, I want a Feedback object, so that I can monitor Feedback,” can be refined, to not be circular: “as a Product Manager, I want to implement a Feedback object with customizable fields, so that I can capture diverse customer insights and improve product development.” The latter clarifies the need and the expected benefit.

Keep each story focused

In writing user stories for Salesforce, clarity is paramount. It’s often said, that stories should be kept short. But, the real goal is to fully communicate the necessary change, no matter the length. A user story must stay focused, on the specific change it’s meant to address. This is easier to achieve, with the support of a business process diagram and when it’s directly tied to business requirements. 

Documented metadata serves to keep the narrative on track, providing clear pre and post-development insights for the change. 

Caution is advised to avoid over-documentation, which can lead developers astray. It’s essential to be precise and avoid including unnecessary details, that are not relevant to the change required.

Make sure each story is testable

To ensure that a Salesforce user story is testable, you need to follow some established best practices during the story creation, here are some of those best practices: 

  • Define clear acceptance criteria: Each user story, should have clearly defined acceptance criteria, that specifies the conditions that must be met, for the story to be considered complete.
  • Incorporate user scenarios: Include real-world scenarios, that the user may encounter, which helps with creating test cases, that mimic user behavior.
  • Leverage behavior-driven development (BDD) techniques: By structuring your acceptance criteria in the format of “given [context], when [event], then [expected outcome],” you create a clear, testable scenario, that can guide both development and testing efforts. This approach not only clarifies what needs to be developed, but also aligns it with the business behavior, ensuring that all stakeholders have a common understanding of the story’s objectives and how they will be validated.

Avoid circular reasoning

Avoid circular reasoning in user stories. A story that states the obvious, doesn’t provide value and can often be misleading or uninformative. The purpose of the story should be to provide clear, actionable insights, into what is needed and why it’s necessary – not, to reiterate the role’s function or title.

Manage user stories

Centralizing the capture of user stories is another pivotal step. Utilize a single system to gather and manage user stories. Use a story should be tracked through a series of statuses in its life cycle. This consolidation helps to avoid fragmentation and ensures that nothing falls through the cracks. It also simplifies the process for stakeholders to review, prioritize and reference user stories, throughout the development cycle.

DevOps integration

Ensure that the development team has access to the user story and any linked documentation or data. Transparency and availability of information, are key for developers to understand, implement and deliver on the user story requirements, effectively. This collaborative approach, not only streamlines the workflow, but also enhances the quality of the end product, as developers can directly align their work, with the specified needs.

To summarize

What Are User Stories?

A User Story is a statement that’s structured; “as a [role], I want to [action], so that I can [outcome]”, that outlines the work you need to complete to the overall business requirement. A User Story articulates what an end user wants to achieve and why, breaking down potentially complex functionality into manageable and understandable pieces.

The user story is the critical handover document from the business to the development teams. Therefore it’s important that is unambiguous, easily understood, but also includes links back to the supporting information, to give it context.

What Is Salesforce?

Salesforce is a cloud-based software company known primarily for its customer relationship management (CRM) product. CRM is a technology for managing all your company’s relationships and interactions with customers and potential customers. Salesforce’s services allow businesses to use cloud technology to better connect with customers, partners, and potential customers.

It’s widely regarded as one of the world’s most innovative companies, and it’s made a big

Before writing user stories:

  • Grasp the driving factors (the why), objectives (the what) and involved parties (the who) behind the change.
  • Evaluate the influence of the change, on current operational workflows.
  • Ensure stories are documented in alignment with the targeted business capabilities.

After writing user stories:

  • Construct a detailed change manifest, capturing the documented affected metadata items.
  • Enhance understanding of the organization’s risk profile, concerning the proposed changes.
  • Determine and document the anticipated impact of the change, on the organization’s processes and systems.

Understanding the complete lifecycle of change, is pivotal when dealing with Salesforce user stories. The true value lies not just in the documentation, but in the holistic approach to the entire change process. This includes the strategic work conducted before and the insightful analysis performed after documenting the stories. 

To maximize the effectiveness of this lifecycle, centralizing all activities within a Change Intelligence Platform, is indispensable. It provides a singular, cohesive framework, that helps in capturing the nuances of the pre-documentation preparation, the intricacies of the actual documentation and the critical evaluations following it.

Back to News