Construct a User Story

Learning Objectives

After completing this unit, you’ll be able to:

Highlight the importance of establishing an acceptance criteria.
Summarize the INVEST concept to writing a user story.
Identify common mistakes to avoid when writing a user story.

Project Team: Assemble!

It’s recommended that a user story-writing workshop is held near the start of a project. Story-writing workshops are organized to include the project team: product manager(s), developer(s), admin(s), UX designer(s), users, and so on. Participants brainstorm to generate story ideas. As user stories develop, the creativity of the entire team should be engaged. And these initial user stories are not written in stone. The beauty of user stories is that they encourage iterative development and can be refined as many times as needed.

When formulating user stories with your project team, don’t make any assumptions about how the user stories will be implemented, such as which components or services will be affected. The development/implementation team makes those decisions during their planning meetings.

Accept the Need for Criteria

It’s natural that when a project group is brought together, the same problem will be seen from different angles. These different perspectives are extremely necessary and useful but can be frustrating if there isn’t an agreed upon gauge of success—otherwise known as acceptance criteria. Acceptance criteria are a set of statements, each with a clear pass/fail result, added to a user story. Put simply, acceptance criteria specify conditions under which a user story is fulfilled. They should be expressed clearly, in simple language, without any ambiguity about the expected outcome. Well-written acceptance criteria benefit multiple stages and stakeholders of a project, including:

Clarifying the scope for the project team
Assisting the development/implementation team
Ensuring testers know what should be tested

Acceptance criteria should state intent, but not a solution. Think of the what, not the how.

Bad example of acceptance criteria because it focuses on solution: A district manager can click an Approve/Disapprove button to approve a discounted product price.
Good example of acceptance criteria because it focuses on intent: A district manager can approve or disapprove a discounted product price.

Once the workshopping of the user story statement is finished, it’s time to add the acceptance criteria. Let’s go back to the user story from the previous unit.

User Story Example: As a customer care representative, I want to be able to take ownership of new cases and communicate with customers so that I can provide high-touch customer experiences.

Examples of acceptance criteria for this user story can be:

Take ownership of cases from the queue.
Email customers from the case page.
Update case details: status, subject, description.

Acceptance criteria can also be formatted as if/then statements. Here’s the acceptance criteria from above written as an if/then statement: If on a case page, then the email customer feature is accessible. Regardless of format, every user story should have at least one acceptance criteria. Each criteria should be independently testable and answered with either a true or false.

Feeling good about acceptance criteria? Time for a little practice. Select the applicable acceptance criteria for the listed user story example.

You may be thinking, how will I remember all of these details when writing user stories and acceptance criteria? Hint: Time to invest in memorizing an acronym.

Invest in the User Story

If your personal to-do list includes “learn about a new checklist,” good news! You’re about to check that off your list. Salesforce business analysts can use the INVEST checklist (created by Bill Wake in 2003) to assess the quality of a user story. If the user story doesn’t meet one of the checks, it probably needs a rewrite.

A successful user story is:

Independent: User stories should be independent and not overlapping in concept with another user story.
Negotiable: A user story is not a contract. A story is an invitation to a conversation. It captures the essence, not the details.
Valuable: The user story needs to be useful to the end user. If a story does not have value, it should not be created.
Estimatable: A successful user story’s timeline can be estimated. An exact estimate is not required, but just enough to help prioritize and schedule the story’s development/implementation.
Small: Most effective user stories are small. Smaller user stories tend to get more accurate timeline estimates. Remember, the details can be elaborated through conversations.
Testable: A good user story is testable. For a successful story, anyone on the project team can look at the user story and say, “Yes, I understand this user story so well that I can write acceptance criteria for it.”

Mistakes to Avoid

Much like any other process that involves multiple steps, mistakes can happen—and user stories are not exempt from such missteps. Thankfully, user stories are adjustable, so there’s always room to iterate. But why not do your best to avoid mistakes from the get-go? Here are a few common user story mistakes and tips for how a Salesforce business analyst can steer clear of them.

The project team didn’t engage in story writing.

Result: The user story will not represent the multiple perspectives of the project team. Extensive rewrites of the user story is inevitable.
How to avoid: Schedule a story-writing session at the beginning of the project. Continuously review and discuss the user story with project team members.

The who of the user story is an undefined user.

Result: Development team will struggle to understand the role of this user’s motivations and needs, as it is undefined. User story will not produce the intended result.
How to avoid: Before creating a user story, create a list of personas of defined users. These well-defined personas can then be referenced when creating a user story, developing/implementing the solution(s), and testing.

The why in the user story is feature specific.

Result: The user story is overly technical and focused on specifics, reading more like a description of the tool than a story. User needs are not addressed.
How to avoid: Keep the user’s needs priority number one. Review the user story after it’s written to see if it focused too much on specifics. Always welcome feedback from the project team.

The acceptance criteria is too vague.

Result: Without specific testable acceptance criteria, there’s no reliable way to measure when the user story is successfully completed.
How to avoid: Ensure all acceptance criteria are independent and can be answered with true or false. Work with the project team to write acceptance criteria that aligns with the goal of the user.

The user story was assigned to the implementation team without a team discussion.

Result: Likelihood of user stories being misinterpreted during development is greatly increased. End product may be far from what was intended.
How to avoid: Review stories with your team when assigning them. Review details, highlight intention, and ensure the team is on the same page.

As you can see, all of these mistakes are avoidable when the user story process is properly followed. Shortcuts should not be taken. Trust the process and the end result will be a solution focused on customer/end-user success.

The obvious definition of user stories being stories about users doesn’t seem so far off now, right? You’ve learned a lot about user stories: purpose, parts, participants to involve, how to test, mistakes to avoid, and even an acronym to help assess a user story. Now use your newfound knowledge about your new best friend and go write some stories about users.