User stories from interviews: template and acceptance criteria

A user story describes value, not a button

A user story briefly describes a desired outcome from the perspective of someone using a product. A common format is “As [role], I want [action] so that [benefit].” This starts a discussion about the need. Requirements and validation still need separate attention.

“Add a green button” suggests a solution. To write the story, find out what the person is trying to do and why the current workflow gets in the way. Keep the original remark so you can test your interpretation.

How to write a user story from an interview

1. Choose a specific episode

   Find the last real instance. Who acted, what did they work with, and what outcome did they need? “Everyone needs reports” does not justify a separate story.

2. Record the exact words and context

   Keep the timecode and a few surrounding sentences. Separate the speaker’s words from your conclusions. Avoid treating an exceptional situation as routine.

3. State the role, action and benefit

   Name a role that explains the situation. Make the action observable. State why the action matters to that person.

4. Check the scope

   A single story should not cover everything from registration to an annual report. Pick a self-contained outcome the team can discuss and test separately.

5. Add acceptance criteria

   Write conditions that make it clear whether the behavior works. Include the main case and one important exception. Agree on them with the team before treating them as customer requirements.

6. Bring open questions back for discussion

   If access roles, data volume or the output format are unclear, write down the question. Avoid filling the gap with the most familiar solution.

From a coordinator’s remark to a story card

The example is about a fictional notes system and does not describe Transkribator’s features. The need is to share selected material without extra information. A button of a particular color is only one possible solution.

The story has a source, but there is no evidence yet that it matters to most customers. One recording captures one experience. Prioritize development separately using other evidence, product goals and implementation cost.

How a story differs from a list of technical tasks

“Create a database table” and “add a handler” are technical tasks. They can help implement a story, but do not explain the user benefit. Conversely, a well-phrased story does not show the team understands every constraint.

Explain the story to a tester without naming an interface element. If you cannot say what the person does before and after, revisit the interview. Check negative cases such as no selected data, insufficient permissions or retrying. Keep only exceptions that matter to this story.

A story card with evidence and open questions

Story title:
Role and work context:
As [who], I want [action] so that [benefit].

Source: interview / date / timecode:
Original remark:
Our interpretation:

Acceptance criteria:
1. Given [condition], the person can [action] and gets [outcome].
2. If [important exception], [expected behavior] occurs.

Outside the scope:
What remains unclear:
Who confirmed the wording and when:

• The role is specific and the benefit is clear.
• The quote is distinct from the team’s decision.
• The criteria can be checked by observation.
• Open questions are marked as such.