| Scope | Phases | Roles | Activities | Abstraction/Refinement Level |
|---|---|---|---|---|
From entire system to individual features |
Analysis, requirements engineering |
Agile team; business analysts, domain experts; application architects |
Iteration planning, development, test; story mapping, story splitting |
Multiple (invitation for conversation) |
also known as: Feature, Backlog Item
A user story is an invitation to a conversation about a particular system feature, and may also capture the results of such conversation.
The Agile Alliance describes the role and purpose of user stories in its glossary entry for them as "divide feature into units that fit into a single iteration" and advises to INVEST in actionable insights on user wants and needs.
User stories come in and out of Story Splitting. Stories also are excellent input to API design and system decomposition.
User stories are used in sprint planning sprint reviews, both when developing a Minimum Viable Product (MVP) and in later iterations. They are one way of communicating about and eliciting functional requirements (or features).
A popular format "role-feature-benefit" (or who-what-why) comes from Connextra:
As a
[role/persona], I want to[feature, in verb form]so that[benefit].
See the glossary entry at the Agile Alliance for more information about the template (and user stories in general).
The Context Mapper and MDSL demo described in ZIO's blog starts with this story that employs the role-feature-benefit template:
As a Researcher
I want to create a PaperItem
with its "title", "authors", "venue"
in a "PaperCollection"
so that other researchers can find and cite the referenced paper easily,
and my h-index goes up.User stories typically are created and updated transiently in issue tracking systems. They can also go to wiki pages, specification and documentation documents.
The Context Mapper DSL has first class support for a role-feature-benefit user story format. Since Version 6.12, Context Mapper also supports ethical Story Valuation and other forms of stakeholder-value modelling, as suggested in Value-Driven Analysis and Design.
- Do not create models or specifications as an excuse for interactions and conversations with end users of the software under construction. When creating libraries, frameworks, or APIs, the client developers are your users.
- Do not confuse benefit with outcome in the third part of the role-feature-benefit template. The glossary entry at the Agile Alliance clearly states: "So that (why they want to accomplish that thing)". The benefit should outline (business) impact and not formally specify a postcondition or computation result (other practices and templates such as given-when-then can be used for that).
- Continuously update the stories while learning about users and their requirements.
- INVEST in story quality.
- Practice Story Splitting to make stories fit into single sprints/iterations (and to identify candidate components for architecture modeling, including potential API endpoints). Also consider story mapping and example mapping.
The role-feature-benefit template usage is rather easy to spot; whether or note INVEST is achieved requires a little more effort.
The presence of one or more of the "three Cs" Card, Conversation, Confirmation can also indicate use.
See glossary entry at the Agile Alliance for "Origins" information.
- Use Cases
- Story Splitting
- Job Stories
- Test-Driven Development (TDD)
- Behavior-Driven Development (BDD) and Given-When-Then template for acceptance criteria.
Mike Cohn's book "User Stories Applied" is a seminal reference (@Cohn:2004).
Many experience reports at Agile conferences deal with user stories; see this collection, for instance.
"How to Write High-Quality User Story" on Medium covers stories in context comprehensively.
title: "Design Practice Repository (DPR): User Stories"
author: Olaf Zimmermann (ZIO)
date: "08, 30, 2024"
copyright: Olaf Zimmermann, 2020-2024 (unless noted otherwise). All rights reserved.
license: Creative Commons Attribution 4.0 International License