When managing any Salesforce project, one of the keys to success is the creation of properly written User Stories. These will provide your team with the building blocks they need to complete the project successfully.
What Is a User Story?
A User Story is essentially a task – a piece of work that needs to be completed to help satisfy the overall business requirements. It is the smallest unit of work in an Agile framework. It is an end goal, as expressed from a User’s perspective, and typically follow the layout:
As a [role], I want to [specific action], so that I can [outcome].
For example: As a Sales Rep it Territory XYZ, I want to have all XYZ Leads automatically assigned to me, so that I can ensure no leads in my territory are left unassigned.
A user story will also have an acceptance criteria, which is used to assess if the requirement has been properly delivered.
So, how do you make sure that the User Stories you are writing are actually good User Stories, and set your team up for success?
We recommend following the INVEST framework:
User Stories should be Independent
Stories should be as independent as possible. When dependencies come into play, it may not be possible to implement a valuable story without implementing other much less valuable stories. By keeping stories independent, changes to one story won’t have a major impact on others.
User Stories should be Negotiable
A story is an invitation to a conversation. The actual result needs to come from the collaborative negotiation between the customer/Product Owner, developer and tester (at a minimum). The goal is to meet customer needs, not develop something to the letter of the user story if doing so doesn’t actually help you to achieve the end goal. Remember to ask lots of questions to help drive the conversation. In that conversation the story may be enhanced or re-written.
User Stories should be Valuable
User Stories should be valuable to the user (or owner) of the solution/ customer/organization. They should be written in plain language and should be features (not tasks) that provide real value to the end users.
User Stories should be Estimable
A story must be able to be estimated or sized so it can be properly prioritized. In a situation where the story can’t be estimated, it can be broken into smaller pieces and help gain more clarity. In the case where story splitting doesn’t help, do some additional research about the story, but be mindful to Time-box the research/Spike.
User Stories should be Small
User Stories should be small enough to be developed and tested during one product sprint. Not too small that they’re creative administrative busywork, but not so large that they’re difficult to plan tasks/prioritize.
User Stories should be Testable
Story should be easily testable to confirm that the story is DONE. This requires proper acceptance criteria in the user story to check whether the story has been implemented in the appropriate way.
Do you have any questions or want to chat about how your organization is managing Salesforce Sales Cloud and Marketing Cloud projects? Get in touch! We’d love to hear from you.
