User Story

A user story is a central element in agile methods that describes a functionality from the perspective of a user. User stories are deliberately kept concise and focus on WHO wants to do something, WHAT should be done, and WHY it is valuable. They serve as the basis for discussions between the development team, Product Owner, and stakeholders.

Structure and Format of a User Story

The classic structure of a user story follows the format:

As a <role/user type> I want to <goal/wish> so that <benefit/value>.

Examples:

• "As an online shopper, I want to filter products by price so that I can find items that fit my budget."
• "As a project manager, I want to see the progress of all tasks in an overview so that I can identify endangered deadlines early."
• "As a mobile user, I want to operate the website with one hand so that I can navigate easily while on the go."

Properties of Good User Stories

The INVEST principle describes the properties of high-quality user stories:

• Independent: A story should be implementable on its own without strong dependencies on other stories.
• Negotiable: The details of implementation are not fixed in advance but are worked out within the team.
• Valuable: A story must deliver recognizable value for users or customers.
• Estimable: The team must be able to reasonably estimate the effort for implementation.
• Small: Stories should be small enough to be implemented within a sprint.
• Testable: There must be clear criteria by which completion can be verified.

User Stories vs. Requirements Specifications

User stories differ fundamentally from traditional requirements specifications:

User Stories	Requirements Specifications
Short and concise	Extensive and detailed
User-centered	Often technically oriented
Emphasize benefit ("Why")	Focus on functionality ("What")
Starting point for conversations	Final contract document
Emerge and develop iteratively	Comprehensively defined in advance
Flexibility in implementation	Strict implementation specifications

The 3 C's of User Stories

User stories are often described according to the "3C" principle:

1. Card: The physical or digital card on which the story is noted in a few sentences. It serves as a reminder for a conversation.
2. Conversation: The dialogue between stakeholders, Product Owner, and development team in which the details of the story are worked out.
3. Confirmation: The acceptance criteria that define when a story is considered "done."

Acceptance Criteria

Acceptance criteria are an essential part of user stories. They concretely define which conditions must be met for a story to be considered successfully implemented.

Example of acceptance criteria for the story "As an online shopper, I want to filter products by price":

• Users can specify a minimum and maximum price
• Price filtering is applied in real time without reloading the page
• A price slider is available and works on mobile devices as well
• After applying the price filter, only products within the price range are displayed
• The currently applied price filter is clearly shown to the user

Acceptance criteria are often formulated in the "Given-When-Then" format:

• "Given I am on the product overview page, when I set the price filter to 50-100 €, then only products in that price range are displayed."

User Story Mapping

User Story Mapping is a technique for placing user stories in a larger context and organizing them:

• Stories are grouped horizontally by user activities (the "backbone")
• Vertically, stories are arranged by priority or development order
• Enables visualization of the user journey and product scope
• Helps identify gaps in the feature set
• Supports release planning through visual prioritization

Size and Granularity of User Stories

User stories exist at different scales:

• Epics: Large, comprehensive stories that are too large for a single sprint and must be split into smaller stories.
• Features: Medium-sized stories that can encompass multiple related functionalities.
• User Stories: The standard size, ideally implementable within a single sprint.
• Tasks: Technical tasks required to implement a user story.

"Slicing" (splitting) large stories into smaller, actionable units is an important skill in agile teams. The resulting stories should still deliver standalone value.

Prioritization of User Stories

User stories are prioritized in the Product Backlog, with various factors considered:

• Business Value: How important is the functionality for the business goal?
• Risk: Does the story contain technical or business risks?
• Dependencies: Is the story a prerequisite for other important features?
• Effort/Benefit Ratio: Is the effort proportionate to the expected benefit?
• Learning Value: Does implementing it provide important insights for further development?

Common prioritization techniques include:

• MoSCoW (Must have, Should have, Could have, Won't have)
• Kano Model (basic, performance, and excitement factors)
• Relative value prioritization
• Buy a Feature (stakeholders "buy" features with a limited budget)

User Stories in Different Agile Frameworks

User stories are handled differently in various agile approaches:

• Scrum: Stories are the main units in the Product Backlog and are selected during Sprint Planning for the Sprint Backlog.
• Kanban: Stories flow continuously through the workflow, without fixed sprint boundaries.
• XP (Extreme Programming): User stories are often linked to Acceptance Test-Driven Development (ATDD).
• SAFe: Stories are organized hierarchically into epics, features, and stories and are relevant at team, program, and portfolio levels.

Common Challenges and Solutions

• Too Technical Stories: Redirect focus back to the user perspective, work out the "why."
• Too Large Stories: Form vertical slices that deliver standalone value.
• Unclear Acceptance Criteria: Formulate test cases, gather examples, conduct workshops.
• Missing Context: Discuss stories in the context of user journeys or story maps.
• Over-Specification: Focus on outcomes, not detailed solution paths.

Tools and Templates

Various approaches and tools are used to manage user stories:

• Physical Boards: Sticky notes on whiteboards or Kanban boards
• Digital Tools: Jira, Trello, Azure DevOps, GitHub Issues, Pivotal Tracker
• Templates: Templates for stories and acceptance criteria
• Workshop Formats: Story-writing workshops, Backlog Refinement, User Story Mapping

In practice, it is less important to strictly adhere to a specific format than to capture the essence of the user story: the user, their goal, and the associated value. User stories are a communication tool that helps teams focus on user needs and collaboratively develop valuable software.