User Stories: Your Secret Weapon for CRM Success
When we launched Idealist Consulting in 2006, Salesforce was little more than a glorified Rolodex. How times have changed.
Today, Salesforce and CRM solutions can be everything from your business’ therapist to its psychic, and customers are rightfully beginning to use it to serve their entire business process. With this expanded usage, it’s more important than ever to have well-defined expectations and goals.
One way that we help our clients manage expectations and meet their CRM implementation goals is by going through the exercise of creating user stories. This can be a useful exercise for organizations of all sizes, regardless of whether you’re working with a consultant or implementing yourself.
What is a user story
A user story is a narrative of what each key employee who will be using Salesforce does. Importantly, a user story does not include how they do it, or the technology they use; this comes later. A user story includes 3 key pieces of information: who (their role), what (they need to do), in order to support what function.
Here’s an example: “As a Gifts processor, I need to be able to track recurring donations on a monthly basis in order to report on fundraising goals."
The value of user story documentation is tremendous because it creates a clear point of reference for whether a project succeeds or not, and helps determine when a project is complete by having something to go back to and say, “did we achieve this?”
Salesforce projects are often executed in an agile style where client and consultant are working together on iterations rather than a linear path, and user stories can help provide a solid foundation for these developer sprints and modifications.
How to collect user stories
There are many ways of going about collecting user stories. If you are working with a consultant, usually there is a discovery process at the beginning of your project that uncovers the key project goals and functional areas. These are your framework for user stories.
Start by documenting the business processes at a high level. What are the steps that your users need to go through in order to do their jobs? Keep in mind that this is outside of how they use technology. You don’t want to capture the steps they use in DonorPerfect to enter a donation because they won’t be using DonorPerfect anymore. What you want to focus on is action and outcome.
Here’s another user story example: “As the marketing manager, I need to send monthly newsletters to constituents based on their previous projects with us.”
Keep documenting until you have captured each step of each key users’ process. During your discovery stage, you should identify all the areas for which you need to produce stories. Process flows can also be a helpful tool in defining user stories. If you go through process flows or swimlane diagrams you can go into small user stories to go through processes and create mini ones.
Each user story should capture the following:
- a description of the functionality they want in Salesforce (in non-technical language)
- what user ‘hat’ they are wearing for the story (such as marketing, development, programs, etc.)
- what they want to do and why from a functional standpoint (such as event registration, membership management, participant management, etc.)
- what steps they will take in order to do the work they want to do
How to track user stories
We track user stories in Salesforce using our proprietary package, Idealist Story Navigator. User stories are drafted and then imported into the Idealist Story Navigator. This allows clients to take advantage of Salesforce right away and get in the system sooner rather than later for user story review. Idealist Story Navigator also houses your Sprints, Test Scripts, and User Acceptance Testing Feedback.
If you want to learn more about how we conduct our projects, take a look at this article.
Challenges to watch out for
By now you can probably see that it is critical to involve all potential users in creating user stories. This will be your protection against reaching that dreaded point where you launch Salesforce and… nothing happens because users aren’t on board.
If you’ve engaged all users through user stories early on, they will have a better sense of what to expect and how they can use the CRM.
How to know when user stories are complete
Make sure to have a clear sign off between the user and the database builder (even if you’re doing this internally) with clear acceptance criteria. This way you mutually agree when the user stories are complete. Be clear on who “owns” this document and what the implications to the project will be if you change user stories after this mutual sign-off has occurred.
Generally, it’s okay to modify a user story before system development starts, but if you’ve begun it is best practice to start a new user story rather than modifying an existing one.
In addition to determining when a user story is complete, you’ll also want to define completion of functionality in your database. It’s important to determine this beforehand so everyone involved is clear when an item is completed and you can move on to the next area of functionality.
Completion could be that the functionality works. It could be that functionality works and testing is completed, or that User Acceptance Testing (UAT) has been completed, and it's fully documented for training purposes.
In summary, here are the best ways to set yourself up for success with user stories:
- make sure every Salesforce user is represented
- have a clearly defined sign-off point
- end users should own user stories
If you include this in your project, your chances of success with Salesforce will be much higher.
Want to learn more about how we apply our project management style to help you in Salesforce? Let’s chat about your project and how our approach can help you be more successful.
