User Stories
It is easy to confuse User Stories with User Scenarios or Use Cases but the three are different.
User stories are concise, user-focused descriptions of desired functionality or features within a software development or product management context.
They capture the needs, goals, and motivations of the end users in a simple and understandable format.
User stories typically follow the template:
"As a [type of user], I want [a particular action or capability] so that [a specific benefit or outcome]."
They also contain details about what should happen, driven by context and other situations:
"If [context] and [additional context] when [event] then [outcome]."
As a jogger I want to track the distance I jog every week so that I can have a good understanding of how much I have exercised. If I stop jogging and I stop for more than fifteen minutes, then the record of my jog should be saved as a new jog.
These stories help prioritise and communicate user requirements in an accessible way, guiding the development team's understanding of what needs to be built.
User stories provide a user-centric perspective, allowing teams to focus on delivering value to users and aligning product development efforts with user needs. They serve as a foundation for agile development, aiding in iterative development, and facilitating collaboration between stakeholders, designers, and developers.
User Stories / Job Stories / Technical Stories
Deciding which "story" to use depends entirely on whose problem you are trying to solve and how much context you already have about the user's motivation.
Think of these not as competing formats, but as different lenses for looking at a product requirement.
User Stories
As a [type of user], I want [action], so that [value].
When to use Use these when the persona is the most important variable. They are ideal for features where different types of users have distinct goals.
The Strength They keep the focus on "who" is doing the action.
The Pitfall They can become repetitive if every user wants the same thing, or if the "so that" clause is just a restatement of the "I want" clause.
Job Stories (Jobs-to-be-Done)
When [situation], I want to [motivation], so I can [expected outcome].
When to use Use these when the trigger or context is more important than the persona. In many apps, a "First Time Parent" and a "Grandparent" might have the exact same motivation when a baby starts crying.
The Strength They focus on the causality of an action. They help designers understand the emotional or situational "why" rather than just a functional "what."
The Pitfall They can feel a bit abstract for very simple, administrative tasks where context doesn't vary much.
Technical Stories
In order to [achieve system goal], we need to [technical implementation].
When to use Use these for work that provides no direct, visible value to the end user but is necessary for the product to function. This includes refactoring code, setting up servers, or migrating databases.
The Strength They allow developers to track "under the hood" work that still consumes time and resources.
The Pitfall If your backlog is 80% technical stories, you are likely focusing too much on the "how" and losing sight of the user's needs.
Further Reading
Last updated