User Stories

User Stories capture requirements from the user's perspective. Each story describes a feature or capability in terms of who needs it, what they need, and why they need it. Stories organize into epics, link to implementing tasks, and track acceptance criteria for completion.

The Problem This Solves

Tasks alone lack context. "Build login form" does not explain who uses it or what success looks like. Without user-centered requirements, developers make assumptions, stakeholders get surprises, and products miss the mark.

User Stories bridge the gap between product vision and implementation. They ensure everyone understands not just what to build, but who it serves and what outcome it enables. Tasks become implementations of clearly understood user needs.

What You Are Looking At

The User Story view displays when you navigate to a specific story from your project. The interface uses a tabbed layout with four primary views: Board, Team, Analytics, and Details.

Each story shows its code identifier, title, and key metadata. The tabs provide different perspectives: the board shows implementing tasks, team shows assigned members, analytics tracks progress, and details show full story information.

User Story Tabs

Board Tab

The Board tab shows a filtered Kanban board displaying only tasks linked to this user story. All standard Kanban features work here: drag and drop, task cards, column management.

This view answers: "What tasks implement this story and what is their status?"

Use the Board tab to understand implementation progress and manage work related to this specific feature.

Team Tab

The Team tab displays all team members who have tasks assigned within this user story. Each member appears as a card with their avatar, name, and role.

This view answers: "Who is working on this feature?"

The team roster builds automatically from task assignments within the story. When someone has tasks linked to this story, they appear here.

Use the Team tab to identify subject matter experts for the feature or coordinate with assigned developers.

Analytics Tab

The Analytics tab provides visual charts analyzing progress on this user story. Visualizations show task completion, effort distribution, and timeline patterns.

This view answers: "How is implementation progressing?" and "Are we on track to complete this story?"

Use Analytics during sprint reviews or when assessing whether a story is ready for release.

Note: Analytics is a Pro feature.

Details Tab

The Details tab shows comprehensive story metadata and allows editing story properties:

Story Title: Editable inline. Click the title text to modify. User story titles typically follow the format "As a [user type], I want [action] so that [benefit]."

Code: The unique identifier for this story (like US-123). Automatically assigned at creation.

Creation Info: When the story was created and by whom.

Priority: The importance level of this story relative to others. Helps with backlog ordering.

Epic: The larger initiative this story belongs to. Epics group related stories for easier management.

Progress: Visual progress bar showing completed tasks versus total tasks linked to the story.

Story Points: Effort estimate for the story as a whole, often used for velocity calculations.

Statistics Row:

• Tasks: Completed versus total task count
• Story Points: Total points assigned
• Worked Hours: Time logged against story tasks
• Comments: Discussion activity

Acceptance Criteria: The conditions that must be true for the story to be considered complete. See Acceptance Criteria for details.

Additional Information: Extended description or notes about the story.

Creating User Stories

To create a new user story:

1. Navigate to your project's user stories list
2. Click the "Create User Story" button
3. Enter the story title (following the "As a... I want... So that..." format)
4. Set priority and epic if applicable
5. Add acceptance criteria
6. Save the story

See Create User Story for detailed creation instructions.

User Story Format

The classic user story format captures three essential elements:

"As a [user type], I want [action/goal] so that [benefit/reason]."

Examples:

• "As a new user, I want to reset my password so that I can regain access to my account"
• "As a team lead, I want to see team velocity so that I can plan sprint capacity"
• "As a client, I want to receive invoice notifications so that I never miss payment deadlines"

This format ensures stories remain user-centered and outcome-focused rather than implementation-focused.

Acceptance Criteria

Acceptance criteria define when a user story is complete. They establish testable conditions that must be satisfied:

Good acceptance criteria:

• Specific and testable
• Written from user perspective
• Cover main scenarios and edge cases
• Independent of implementation details

Example:

Given a user on the login page
When they click "Forgot Password"
Then they should see the password reset form

Given a valid email is submitted
When the reset link is sent
Then the user receives it within 30 seconds

Given an invalid email is submitted
When the form is processed
Then an appropriate error message appears

See Acceptance Criteria for detailed documentation.

Epics and Organization

Epics are large initiatives that group multiple user stories. Use epics to organize related functionality:

• Feature areas: "User Authentication" epic containing login, registration, password reset stories
• Releases: "v2.0 Release" epic grouping all stories planned for that version
• Themes: "Mobile Experience" epic for mobile-related improvements

Assign stories to epics through the epic selector in story details. This enables:

• Filtering by epic in story lists
• Tracking epic-level progress
• Reporting on feature area completion

Linking Tasks to User Stories

Tasks implement user stories. Each task can link to a user story, establishing traceability between work and requirements.

Methods to link tasks:

1. During task creation: Select the user story in the task creation modal
2. From task detail: Add user story association in the task sidebar
3. From story board: Create tasks directly from the story's board view

Linked tasks appear on the story's Board tab and contribute to progress calculations.

Priority Management

User story priorities help order the backlog:

Priority levels may include:

• Critical: Must have for release
• High: Important for core functionality
• Medium: Valuable but not blocking
• Low: Nice to have, can defer

Set priority through the priority selector in story details. Use priority to:

• Order backlog for grooming sessions
• Identify what to implement first
• Communicate importance to stakeholders

Story Points

Story points estimate relative effort:

• Fibonacci sequence: 1, 2, 3, 5, 8, 13 (common pattern)
• Relative sizing: Compare stories to each other, not to absolute time
• Team consensus: Points reflect team agreement, not individual estimates

Story points enable:

• Velocity tracking (points completed per sprint)
• Capacity planning (how many points fit in a sprint)
• Progress forecasting (when will the backlog complete)

Assign points in story details or during team estimation sessions.

Voting and Estimation

Some teams use voting features to collaboratively estimate stories:

1. Facilitator presents the story
2. Team members vote on point estimates
3. Discussion resolves discrepancies
4. Final estimate is recorded

This process surfaces different perspectives and builds shared understanding of story complexity.

User Story Workflow

A typical user story lifecycle:

1. Draft: Story identified but not fully defined
2. Ready: Story has clear acceptance criteria and is estimable
3. In Progress: Tasks are being worked
4. Review: Implementation complete, awaiting verification
5. Done: Acceptance criteria verified, story closed

Track status through story fields or through linked task progress.

Pro Tips

• Story splitting: Large stories should be split into smaller, independently deliverable pieces. If a story cannot be completed in one sprint, it is too big.

• Acceptance criteria first: Write acceptance criteria before implementation begins. They guide development and define done.

• Regular grooming: Review and refine the story backlog regularly. Keep the top of the backlog detailed and ready; allow more ambiguity further down.

• User validation: Whenever possible, validate stories with actual users. A story is not done when code is complete; it is done when users successfully accomplish their goal.

Permissions

User story permissions vary by role:

• Agency Owners and Managers: Full access to create, edit, delete, and manage stories
• Developers: Can view stories, link tasks, update progress
• Clients: View access when enabled, may participate in voting

How to Report a Problem or Request a Feature

Your feedback matters. Here is how to share it:

If user story management could work better for your workflow, we want to hear about it.

In the Sidebar, click on Support Tickets and open a ticket for the problem. Everything is interactive and fast through the GitScrum Studio platform.