Collecting information about your users can be done in many different ways. We start with a discovery phase to uncover users’ goals and functional areas. A user story template can have a standard format, plus it’s easy! We start with the three W’s. 

• Who – This includes their role, job function, or type of user. This can be determined by creating a user persona.

• What – What goal does your end-user hope to accomplish with this product?

• Why – What does your user need this product to do? (To support what function.) 

“As a <who>, I want <what> So that <why>.”

You can begin to look at users at a more granular level. Ensure that you capture each stage of the users’ process and identify each area that will need a story.

 A few examples of user stories are:

1. As an eastern sales rep, I want to automatically be assigned to all eastern leads once they’re entered into Salesforce so I don’t miss any hot leads.

2. As a manager, I want to access sales reports so that I can prioritize my teams’ pipeline. 

3. As a marketing manager, I want to send newsletters to clients who work with us to keep them informed of industry changes. 

It is important to remember that user stories are small. A good user story includes the INVEST set of criteria by Bill Wake: 

• Independent – User stories can be developed in any sequence, and changes to one story don’t affect the others.

• Negotiable – It’s up to the team to decide how to implement them; there is no rigidly fixed workflow.

• Valuable – each user story delivers a detached unit of value to end-users.

• Estimable – It’s quite easy to guess how much time the development of a user story will take.

• Small – it should go through the whole cycle (designing, coding, testing) during one production sprint.

• Testable – there should be clear acceptance criteria to check whether a user story is implemented appropriately.

As previously mentioned, a user story is simple. Let’s breakdown the template,

 “As a <who>, I want <what> So that <why>.” 

Step 1: Who? 

Who are you building this for? It’s all about the user. This is more than a job title; it is the persona of the person. Get to know your users and start with their names. Understand how your John’s or Laura’s work, dive into how they think and feel and what their needs are. It is crucial at this stage to create a user persona. 

Step 2: What?

After determining your end-users, it’s time to define the functionality of the product and how they are going to use it. What is your user trying to achieve? This should be written in non-technical language. Avoid buzzwords or ambiguous terminology. By using accurate and straightforward language, you will better understand the needs of your users; this is their story, after all. 

*Important Tip: Stick to one action per story. For example, “As an admin, I want to create a new user profiles and monitor access levels so I can keep track of employees throughout their employment.” This story would be best if split into two. 

Step 3: Why 

What value are you bringing your end-user? This value should correspond with metrics and KPIs. Ask yourself, does it improve UX, increase retention rates, improve lead generation, the list goes on. Ask your user what problem needs to be solved and how that will add value to their role. 

A user story can be written on an index card or sticky note. In the figure above, you see a simple index card containing all of the information needed for a formal, high-level user story. Let’s review:

• The Three-W’s: “As a <who>, I want <what> So that <why>.” It is essential to collaborate with the stakeholders on this one. User stories should be simple. Anyone can write one.

• Priority: Ranking your user stories allows your development team to determine how to prioritize the work when the production cycle starts. You can use a numerical system or define the priority as High, Medium, and Low. It might get a little confusing when presenting a stack of index cards to your internal team. Once your discovery session is complete, we recommend that you transfer the data to a digital format for easy reference.

• Estimate: This determines the amount of effort it will take to implement the user story. You can come up with your own value to estimate the time, i.e. 1 point = 2.5 hours.

• Unique Identifier: Optionally, you can add an individual ID. An ID is helpful if you need to trace information between user stories and other aspects of your project. 

There are two ways to detail user stories; you will most likely use one or the other at some point. You can include the details on the back of your index card, or easily add it to your digital format by adding a note. 

Split The Story: If you didn’t heed the advice from Step 2, let’s review. It is essential to stick to one action per story. The idea is to break the stories down into iterations. By breaking down user stories, you can deliver smaller portions of the project that will give value to the customer. Splitting user stories can be done in many different ways. 

Acceptance Criteria: Another way to add detail to the story is by using Acceptance Criteria. These details indicate what the story must do for the user to accept it as complete.  

As a user, I can log in through a social media account.

• Acceptance criteria:

  • Can log in through Pinterest

  • Can log in through Youtube

  • Can log in through Facebook

The odds are that during your time creating user stories, you will use either one of the detailing options above. As long as your story is detailed in a way that highlights and resolves your users’ pain points, you’re on the right track! 

Every team has their definition of “done.” It is crucial to determine what you and your stakeholders consider done. Agreeing on what done means enables the team to complete the backlog quickly and accurately — done means that the feature has been developed, tested, and meets all acceptance criteria. Done may also mean that the feature could be presented or shipped to the customer. While not everyone may agree on what the definition of done means, it is vital to establish the DOD with your team and stakeholders early on.

User stories are beneficial to the success of any project. By following a user-centric approach, your team and stakeholders can establish the needs of the end-user and begin to focus on solving real-life problems that the user might face. Including user stories to your next Salesforce project will prove to be beneficial to your success. Contact us today!