Ever wondered what makes a project truly succeed? Picture this: What’s the best way to keep tabs on progress or to measure and plan a project in a straightforward manner? If you thought of user stories, you’re on the right track. Yet, in my experience working on projects of all sizes, I’ve noticed a common pitfall – user stories are often not given the attention they deserve. Teams either skip them and jump straight into designing solutions or praise a high volume of user stories without truly understanding their significance.
It’s disheartening to see user stories either underestimated or overestimated. The truth is that many miss the mark on using user stories the right way and fail to connect the dots between epics, user stories, and acceptance criteria. That’s why I’m writing this article – to shed light on the potential locked within projects and how understanding and using user stories strategically can make all the difference.
Let’s begin by examining the elements within the scope of user stories in a project setting. By connecting the dots, we’ll unravel their relationships and gain a comprehensive understanding.
Epics: Setting the Scene
Think of an implementation project like building a house, and defining epics is the initial step to laying the foundation for everything that follows. Instead of tackling everything at once, break it down into different parts or ‘scopes.’
Each scope is like a floor of the house – a dedicated area for specific tasks, which we call an epic on a project. This strategic approach marks the beginning, setting the groundwork for the entire project and ensuring a strong foundation for future work.
The Concept
An epic in a project setting is intended to set the scene without delving into details. Think of it as the overarching scene that outlines the scope and direction.
An epic provides a broad, high-level view, offering a guiding scene for the various elements within. It’s intentionally light on specifics, serving as a foundational concept that unites and directs the items within its scope.
Method and Approach
Crafting epics in a Salesforce project offers various angles, allowing flexibility based on project goals. Here are two prominent approaches I have adopted over the years:
Functional Area-Based Epics
Example: In a full cycle implementation, such as rolling out Sales Cloud, crafting epics around functional areas like lead management, account and contact management, opportunity management, contract management, forecast management, and other key areas is a common strategy. It’s like dividing the project into distinct parts, ensuring each critical aspect gets the attention it deserves.
Persona-Based Epics
Example: For more unstructured platform optimization initiatives, structuring epics around personas can sometimes be more effective. Each persona – sales managers, sales reps, marketing teams, and operations – becomes an epic, grouping challenges unique to their needs. This approach ensures a tailored solution, addressing the specific pain points of different user roles.
While these are common approaches, the beauty lies in customization. There are numerous other ways to craft epics; the key is to do so considering dependencies and feasibility, ensuring each epic contributes effectively to the Salesforce project’s success.
User Stories: Conceptualizing Purpose
After setting up the scene, we focus on the basics within it, kind of like when you plan the rooms on a certain floor. In the project world, these rooms act as blank spaces for specific purposes.
Think of the living room as a user story – it’s like having an idea to create a spot for relaxing after work (the idea), making you feel physically and mentally at ease (the purpose). This user story gives us a clear picture without getting too bogged down in the ‘nitty-gritty’ details.
The Concept
User stories are like building blocks in a project, expressing ideas and their purpose. Think of them as placeholders – simple concepts answering who, what, and why. They’re the storytellers that give you a clear picture and basic ideas without getting too complicated. User stories are the main components in a larger picture, helping everyone understand the direction and what we’re trying to achieve.
User stories typically follow a simple format: “As [the persona involved], I want to [the intended action] so that I can [the underlying motivation].”
I strongly believe in keeping user stories short and to the point. They should be intentionally built, offering enough breadth for a complete narrative without unnecessary details. The goal is to make them extremely easy to read, ensuring a clear understanding of the user’s needs and motivations without overwhelming anyone with excessive explanations.
Common Mistakes
Overcomplicated Statements with Excessive Explanations
If you’re explaining the action with instructions or intention with explanations, your story becomes less readable and mixes the concept of acceptance criteria with user stories.
Example: “As a Sales Representative, I want to navigate to the Opportunity tab in the Salesforce application, click the New Opportunity button, fill in the required fields, and then click the Save button, so that a new opportunity record is created in the system, and this opportunity can be associated with an existing account, contributing to the overall pipeline.”
Embedding Technical Design into the Story
One of the most common mistakes in Salesforce projects is embedding technical details into user stories. User stories are for business users and represent conceptual requirements. Mentioning specific technical mixes the concept of solution design with user stories.
Example: “As a Support Agent, I want to create a case in Salesforce with a validation rule that checks if the client has a membership so that the SLA with the members is maintained.”
Having the Same Intended Action and Motivation
Another common mistake is having the same intended action and motivation, indicating a lack of proper discovery of the user’s pain points. This makes user stories non-testable and hinders measuring the project’s success.
Example: “As a Sales Representative, I want to create a new lead in Salesforce so that the lead can be created in the system.”
Method and Approach
Efficiently identifying and structuring user stories is crucial for successful project management. Over the years, I’ve found these approaches highly effective in organizing user stories based on the project’s nature and requirements:
User Journey-Driven Approach
Suitable for projects involving an end-to-end process within the scope. This approach is diagram-driven, with swimlane processes conducted for each functional area (epic). Each element on the diagram translates into a user story, making it a visual-friendly and organized method. Ideal for projects with potential process changes in the future.
List-Driven Approach
Appropriate for enhancement or managed service projects. Challenges faced by personas or functional departments (epic) are listed, and each challenge is reversed into a motivation for a user story. This method aids in forming accurate success indicators for the project.
Feature-Driven Approach
Suitable for projects with heavy front-end work, such as Experience Cloud implementation. Stories are categorized into front-end and back-end parts for each functional area (epic). Helps in organizing stories logically, making it easier to distribute tasks among the team based on their skill sets.
Acceptance Criteria: Translating Ideas into Detailed Scenarios
In our living room example, the user story outlines who (you) does what (relaxing) for what purpose (unwinding after a long day). Now, within the user story, picture acceptance criteria as the detailed instructions – specifying how to arrange the cushions, set the lighting, and choose soothing music.
In this scenario, user stories provide the ‘what’ and ‘why’ (relaxing in the living room), and acceptance criteria inside them provide the ‘how’ (the step-by-step guide). It’s akin to having a checklist that you mark off as you create the perfect atmosphere. The crucial features of acceptance criteria are that they must be testable and measurable, ensuring we’re following the right steps for each relaxing-building block in our development process.
The Concept
Acceptance criteria are the storytellers in the project, creating scenarios that guide us toward the user story’s goal. Each scenario provides a unique angle, offering a clear path to the story’s destination. To be effective, criteria need the right context for testability. They are action-driven, serving as blueprints describing ‘how’ the story unfolds. By focusing on specific actions, criteria provide a clear pathway for solution design and testing. They are the storytellers that turn an idea into a functional reality.
My favorite structure is the “Given… When… Then…” format. It brings clarity to testing and implementation.
- Given: Think of “Given” as the starting point. It is the initial condition or context before something happens.
- When: This represents the action or event that kicks everything into gear.
- Then: This defines the expected outcome or results.
Together, they create a clear and structured way of describing what we want to happen in a scenario. These criteria serve as the compass, guiding development and testing teams toward the successful realization of user stories and features. It’s like telling a simple story: first, this is how things are; then, something happens; and finally, here’s what we expect to see as a result.
Characteristic
Understanding the characteristics of acceptance criteria is essential for their effective use in a project. In my view, acceptance criteria are the key to successful development and testing. They act as the vital link between high-level project goals and the detailed groundwork. Every part of solution design starts with acceptance criteria, turning abstract concepts into concrete realities.
Similarly, test plans are directly derived from acceptance criteria, forming a detailed checklist for validation. Because of their central role in project success, creating and using acceptance criteria requires significant effort and attention.
One common mistake to avoid is tying solution design and test plans directly to user stories. This often leads to challenges in tracing and can result in incomplete designs or tests. By focusing on well-defined acceptance criteria, teams can avoid this pitfall and ensure a seamless connection between project objectives and the detailed implementation.
Relevance to User Goals
This characteristic emphasizes the alignment of acceptance criteria with the end user’s objectives, ensuring that the implemented functionality is meaningful for users. Aligning acceptance criteria with user goals establishes a direct link back to the purpose outlined in user stories and directly contributes to the definition of done (DoD).
Example: Given a user on the password reset page, when the user provides a valid username and clicks “Submit”, then an email containing a secure password reset link should be sent to the user’s registered email address.
Specificity
Specificity in acceptance criteria is about providing clear and detailed guidelines on what needs to be achieved. To keep specificity in acceptance criteria, the key is to place special emphasis on the expected outcome in the ‘then’ part. This involves providing meticulous details, ensuring clarity without any room for ambiguity.
Example: Given a Salesforce custom object, when a user creates a new record, then the Created Month field should be automatically calculated and populated based on the Created Data.
Testability and Measurability
This characteristic is crucial for creating clear and effective test cases, allowing for a highly objective assessment of implemented features.
To achieve this, it’s essential to provide explicit instructions for each action, leaving no room for confusion. By clearly defining expected outcomes, they become tangible checklist items that can be easily verified, ensuring that the criteria are met. This approach not only streamlines the testing process but also enhances overall quality assurance, enabling a robust and objective evaluation of the delivered product.
Example: Given a Salesforce validation rule, when a user attempts to save a record with a blank Email field, then the system should display an error message.
Completeness
Completeness in acceptance criteria ensures a thorough coverage of all aspects within a user story. This includes a variety of scenarios, encompassing both positive and negative cases.
Achieving completeness involves examining outcomes from both success and error perspectives. By defining not only the expected positive scenarios but also considering potential challenges and deviations, the acceptance criteria serve as a comprehensive guide for development and testing. This approach minimizes the risk of overlooking critical functionalities, fostering a detailed understanding of the user story and contributing to its successful implementation.
Example: Given a Salesforce Apex trigger, when a user attempts to delete a record with related child records, then the system should prevent the deletion and display an error message.
Summary: Transforming Concepts into Tangible Items
The relationship among epics, user stories, and acceptance criteria can be conceptualized as a series of nested placeholders. Epics represent the highest-level placeholder, outlining a broad common scene. User stories, one step more detailed, position the purpose within the scope of the epic. Further refining the narrative, acceptance criteria serve as the most detailed placeholders, defining the process of discovering actions to build a clear pathway toward the intended purpose outlined in the user stories.
In essence, it’s a hierarchical structure where each level adds granularity and specificity, guiding the development process from overarching themes down to the detailed actions necessary for successful implementation.