User Story Writing Skill

Purpose

Write clear, valuable user stories that communicate requirements in Agile/Hybrid environments and guide development teams.

When to Use

• Agile or Hybrid projects

• Sprint planning and backlog refinement

• Breaking down features into implementable chunks

• Communicating requirements to development teams

User Story Format

Basic Template

As a [user role] I want [goal/desire] So that [benefit/value]

Enhanced Template (Recommended)

Title: [Short, descriptive title]

As a [user role] I want [goal/desire] So that [benefit/value]

Acceptance Criteria:

• [Criterion 1]
• [Criterion 2]
• [Criterion 3]

Notes: [Additional context, wireframes, business rules]

Definition of Done:

• Code complete and peer reviewed
• Unit tests written and passing
• Integration tests passing
• Acceptance criteria met
• Documentation updated

INVEST Criteria

Every user story should be:

• Independent: Can be developed and delivered independently

• Negotiable: Details can be discussed and refined

• Valuable: Delivers value to users or business

• Estimable: Team can estimate effort required

• Small: Can be completed within one sprint

• Testable: Clear acceptance criteria for testing

Examples by Domain

E-commerce Examples

Story 1: Guest Checkout

Title: Guest Checkout Without Account Creation

As a first-time customer I want to complete my purchase without creating an account So that I can checkout quickly without friction

Acceptance Criteria:

• Given I have items in my cart When I click "Checkout as Guest" Then I can enter shipping and payment info without login
• Given I complete guest checkout When I receive order confirmation Then I see an option to create an account
• Given my order total is over $5000 When I try to checkout as guest Then I am required to create an account for security

Business Rules:

• Guest checkout not available for orders > $5000
• Email required for order confirmation
• Guest orders linked to email for future reference

Story Points: 8 Priority: Must Have Sprint: Sprint 3

Story 2: Real-time Shipping Calculation

Title: Real-time Shipping Cost Display

As a customer I want to see shipping costs before entering payment information So that I know the total cost upfront and avoid surprises

Acceptance Criteria:

• Given I enter a valid shipping address When I proceed to shipping method selection Then I see all available shipping options with costs
• Given I select a shipping method When I view the order summary Then the shipping cost is included in the total
• Given the shipping API is unavailable When I try to calculate shipping Then I see a fallback message with estimated costs

Technical Notes:

• Integrate with ShipStation API
• Cache shipping rates for 5 minutes
• Timeout after 5 seconds, show fallback

Story Points: 5 Priority: Must Have Sprint: Sprint 3

CRM Examples

Story 3: Automatic Lead Scoring

Title: Automatic Lead Scoring Based on Behavior

As a sales manager I want leads to be automatically scored based on their activities So that my team focuses on the most qualified prospects

Acceptance Criteria:

• Given a lead visits the pricing page When the activity is tracked Then 15 points are added to their score
• Given a lead's score reaches 60 When the score is updated Then the lead is automatically marked as MQL
• Given a lead's score reaches 75 When the score is updated Then the lead is assigned to a sales rep and rep is notified
• Given I view a lead record When I look at the lead score Then I can see the scoring breakdown (why this score)

Scoring Rules:

• Demographic: Job title (0-20), Company size (0-15), Industry (0-5)
• Behavioral: Pricing page (15), Whitepaper (10), Webinar (15), Demo request (25)

Story Points: 13 Priority: Must Have Sprint: Sprint 5

Mobile/Web Examples

Story 4: Offline Order Viewing

Title: View Orders Offline in Mobile App

As a mobile app user I want to view my order history when offline So that I can check order details without internet connection

Acceptance Criteria:

• Given I have previously viewed orders while online When I open the app offline Then I can see my cached order history
• Given I am offline When I try to view order details Then I see the last synced information with "offline" indicator
• Given I regain internet connection When the app detects connectivity Then order data is automatically refreshed in background

Technical Notes:

• Cache last 50 orders in local storage
• Use SQLite for offline storage
• Sync on app foreground if connected

Story Points: 8 Priority: Should Have Sprint: Sprint 7

ERP Examples

Story 5: Multi-level Purchase Approval

Title: Multi-level Purchase Order Approval Workflow

As a procurement manager I want purchase orders to route through appropriate approval levels So that spending is controlled according to company policy

Acceptance Criteria:

• Given a PO is created for $1K-$10K When the PO is submitted Then it routes to department manager for approval
• Given a PO is created for $10K-$50K When the PO is submitted Then it routes to department manager, then finance director
• Given a PO is created for >$50K When the PO is submitted Then it routes to department manager, finance director, then CFO
• Given an approver is out of office When a PO requires their approval Then it automatically routes to their designated backup
• Given an approver rejects a PO When the rejection is submitted Then the requester is notified with rejection reason

Approval Matrix:

• $0-$1K: Auto-approved
• $1K-$10K: Department Manager
• $10K-$50K: Department Manager → Finance Director

• $50K: Department Manager → Finance Director → CFO

Story Points: 13 Priority: Must Have Sprint: Sprint 4

CDP Examples

Story 6: Customer Identity Resolution

Title: Unify Customer Profiles Across Channels

As a marketing analyst I want customer data from web, mobile, and CRM to be unified So that I have a complete view of each customer

Acceptance Criteria:

• Given a customer logs in on web and mobile with same email When identity resolution runs Then both profiles are merged into single customer record
• Given a customer has multiple emails When I manually link the profiles Then all activities are consolidated under primary profile
• Given profiles are merged When I view the customer record Then I see all touchpoints across channels in timeline
• Given a merge conflict occurs (different names, addresses) When the system detects conflict Then it flags for manual review

Matching Rules:

• Email (exact match) - High confidence
• Phone + Name (fuzzy match) - Medium confidence
• Cookie ID + Email domain - Low confidence

Story Points: 21 Priority: Must Have Sprint: Sprint 2-3 (2 sprints)

Story Hierarchy

Epic → Feature → User Story → Task

Epic: Large body of work (multiple sprints)

Epic: Mobile App Customer Self-Service Goal: Enable customers to manage accounts via mobile app Timeline: Q1 2026 Stories: 25-30 stories

Feature: Group of related stories (1-3 sprints)

Feature: Order Management in Mobile App Stories: View orders, Track shipments, Initiate returns Sprint: Sprint 5-6

User Story: Single piece of functionality (1 sprint)

Story: View Order History Tasks: API integration, UI development, Offline caching Sprint: Sprint 5

Task: Technical implementation step (hours/days)

Task: Implement order list API endpoint Estimate: 4 hours

Acceptance Criteria Formats

Given-When-Then (Gherkin)

Given [context/precondition] When [action/event] Then [expected outcome]

Example:

Given I am a logged-in customer When I click "View Orders" Then I see a list of my orders sorted by date (newest first)

Checklist Format

• Criterion 1
• Criterion 2
• Criterion 3

Example:

• Order list displays order number, date, total, status
• Orders are paginated (20 per page)
• User can filter by status (All, Processing, Shipped, Delivered)
• User can search by order number
• Clicking an order opens order details

Scenario-Based

Scenario 1: [Happy path] Scenario 2: [Alternative path] Scenario 3: [Error case]

Story Splitting Techniques

When a story is too large (>13 points), split by:

1. Workflow Steps

• Original: "User can complete checkout"

• Split: "Enter shipping info", "Select shipping method", "Enter payment", "Review order"

2. Business Rules

• Original: "Calculate shipping costs"

• Split: "Standard shipping", "Express shipping", "International shipping"

3. CRUD Operations

• Original: "Manage products"

• Split: "Create product", "Update product", "Delete product", "View products"

4. Data Variations

• Original: "Import customer data"

• Split: "Import from CSV", "Import from Excel", "Import from API"

5. Platforms

• Original: "Mobile app checkout"

• Split: "iOS checkout", "Android checkout"

6. Simple/Complex

• Original: "Search products"

• Split: "Basic keyword search", "Advanced filters", "Faceted search"

Story Estimation

Story Points (Fibonacci: 1, 2, 3, 5, 8, 13, 21)

• 1 point: Trivial change (few hours)

• 2 points: Simple feature (half day)

• 3 points: Straightforward feature (1 day)

• 5 points: Moderate complexity (2-3 days)

• 8 points: Complex feature (3-5 days)

• 13 points: Very complex (5-8 days) - consider splitting

• 21+ points: Too large - must split

T-Shirt Sizing (Alternative)

• XS: 1-2 points

• S: 3-5 points

• M: 8 points

• L: 13 points

• XL: 21+ points (split required)

Definition of Ready (DoR)

Story is ready for sprint when:

• User story follows INVEST criteria

• Acceptance criteria are clear and testable

• Dependencies identified and resolved

• Wireframes/mockups available (if UI work)

• Business rules documented

• Story estimated by team

• Priority assigned

• Technical approach discussed

Definition of Done (DoD)

Story is complete when:

• Code complete and peer reviewed

• Unit tests written (>80% coverage)

• Integration tests passing

• All acceptance criteria met

• Manual testing completed

• Documentation updated

• Deployed to staging environment

• Product owner approved

Best Practices

✅ Do:

• Write from user perspective

• Focus on value, not implementation

• Keep stories small and focused

• Include clear acceptance criteria

• Involve the team in writing stories

• Refine stories before sprint planning

• Link stories to epics and features

❌ Don't:

• Write technical tasks as user stories

• Make stories too large (>13 points)

• Skip acceptance criteria

• Write vague or ambiguous stories

• Include implementation details

• Create dependencies between stories in same sprint

Tools

Lark

• Use Lark Base for backlog management

• Create story template with custom fields

• Link stories to epics and sprints

• Track story status and progress

Notion

• Create user story database

• Use kanban board for sprint planning

• Link stories to requirements and test cases

• Template for consistent story format

Common Patterns

E-commerce

• As a customer, I want [shopping/checkout feature]

• As an admin, I want [product/order management]

• As a merchant, I want [analytics/reporting]

CRM

• As a sales rep, I want [lead/opportunity management]

• As a manager, I want [pipeline/forecasting]

• As a marketer, I want [campaign/automation]

ERP

• As a user, I want [process automation]

• As an approver, I want [workflow management]

• As an admin, I want [configuration/setup]

Mobile/Web

• As a mobile user, I want [on-the-go features]

• As a user, I want [responsive/accessible UI]

• As a user, I want [offline capabilities]

Next Steps

After writing user stories:

• Refine with team during backlog grooming

• Create acceptance criteria (see acceptance-criteria skill)

• Estimate during planning poker

• Break into technical tasks

• Link to test cases for UAT

References

• Mike Cohn - User Stories Applied

• INVEST Criteria - Bill Wake

• Agile Alliance - User Story Guidelines

• Scrum Guide - Product Backlog Management