Join this interactive session to understand how to write Salesforce-specific user stories, how to prioritize user stories, and learn some guidelines around story estimation. Join us to learn about Salesforce User Stories in Action and How to Write User Stories for Salesforce.
How to Write User Stories for Salesforce
When writing user stories in Salesforce, it’s essential to keep the focus on the user and their needs. Here are some tips for writing effective user stories:
- Start with the user: Begin each user story with a description of the user and their goal. For example, “As a sales representative, I want to be able to quickly access my customer’s contact information.”
- Use language that is easy to understand: Avoid technical jargon and use plain language that everyone can understand.
- Keep it simple: User stories should be concise and easy to understand. Avoid adding unnecessary details or complexity.
- Prioritize the most important features: Focus on the features that will deliver the most value to the user.
- Define acceptance criteria: Clearly define what constitutes a successful outcome for the user story.
- Collaborate with stakeholders: Involve stakeholders in the user story creation process to ensure that everyone is aligned on the goals and objectives.
By following these guidelines, you can create user stories that are clear, concise and focused on delivering value to the user.
What is Backlog?
A backlog is a prioritized list of identified values (items). That is associated with products/services and results. That is delivered to an identified customer (individual, group, entity/system).
Salesforce User Stories in Action
User Stories refers to the delivery of specific value to a specific user – Provides the Who?, What? & Why?
- Description Format: As a [user], I need [some outcome], so that I can [achieve some benefit/value].
- Decomposition: The User Story must be decomposed into multiple Sub-tasks (actions to be taken). Note: if no Sub-tasks (or only one Sub-task) are identified, then the User Story is likely merely a Sub-task of some other User Story.
- Duration: Must be right-sized to be completed in a Sprint (typically 2 weeks), or in the case of Kanban, a reasonably short cycle time (maybe 2 – 4 weeks)
- Sizing: Typically sized by Story Points.
User Story Point
Story Point Expresses the estimated “size” of a backlog item. Are relative, i.e., are not connected to any specific unit of measure (e.g., time, etc.). Various factors are used to establish a story point value:
- Volume: How many “things” to be done?
- Complexity: How hard/difficult is the work?
- Knowledge: What do we currently know about what needs to be done?
- Uncertainty: What do we currently not know about what needs to be done?
Based on the modified Fibonacci Sequence of numbers (1, 2, 3, 5, 8, 13, 20…)
Using an abstract measure of Story Points makes us focus on relative sizes of Backlog items. Regarding Knowledge and Uncertainty, the team could consider the following:
- Group experience – “We’ve done this before, and we can do it again.”
- Similar experience – “We’ve done something like this before, and we can use what we learned then.”
- Unique experience – “We’ve never done this, but we have the skills in place to figure it out.”
- Individual experience – “I’ve done this before, and I can show others how.”
- No experience – “This has never been done before.”
Size Estimation Games
Development Team can use a pseudo-poker game to estimate (relatively) the size (story points) of backlog items. Examples of virtual games are:
Salesforce User Stories in Action
We will learn about User Story Writing and how User Stories should be Prioritized. Best practices for User Story Estimation. Please subscribe our YouTube channel to get notifications for video uploads.
