How to Write User Stories and Acceptance Criteria – Foundational Application Security

Use the INVEST criteria when formulating user stories

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.
Estimable: 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.”

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.

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 a 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.

A good acceptance criteria does not tell the developers the solution to build (i.e. a button) but should rather focus on intent (ability to approve / disapprove).

This is another good example:

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.

Mistakes to avoid when writing user stories and acceptance criteria

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.