AgentSkillsCN

Agile BA Practices

在敏捷开发与混合开发环境中(如Scrum、Kanban、SAFe)有效运用业务分析实践

SKILL.md
--- frontmatter
name: Agile BA Practices
description: Apply business analysis practices effectively in Agile and Hybrid development environments including Scrum, Kanban, and SAFe

Agile BA Practices Skill

Purpose

Guide AI assistants in applying BA practices within Agile and Hybrid methodologies, balancing lightweight documentation with comprehensive analysis.

BA Role in Agile

Traditional BA vs Agile BA

AspectTraditional BAAgile BA
DocumentationComprehensive upfrontJust enough, just in time
RequirementsComplete before devEmergent, evolving
DeliverablesBRD, FRS, Use CasesUser stories, acceptance criteria
ApproachWaterfall/phasesIterative/incremental
FeedbackEnd of projectContinuous, each sprint
ChangeFormal change controlEmbrace change

BA Role in Scrum

Sprint Planning:

  • Clarify user stories with team
  • Answer questions about requirements
  • Help estimate complexity
  • Identify dependencies

During Sprint:

  • Available for clarification
  • Accept completed stories
  • Refine upcoming stories
  • Write acceptance criteria

Sprint Review:

  • Demo features with PO
  • Gather stakeholder feedback
  • Note change requests

Sprint Retrospective:

  • Reflect on BA processes
  • Improve collaboration

Backlog Refinement:

  • Elaborate upcoming stories
  • Add acceptance criteria
  • Split large stories
  • Prioritize with PO

Core Agile BA Artifacts

Product Backlog

Structure:

code
Epic > Feature > User Story > Task

Example:

markdown
Epic: Customer Self-Service Portal
├── Feature: Account Management
│   ├── User Story: View profile
│   ├── User Story: Update profile
│   └── User Story: Change password
├── Feature: Order History
│   ├── User Story: View orders
│   └── User Story: Track shipments
└── Feature: Support
    ├── User Story: Submit ticket
    └── User Story: View FAQs

User Story Template

markdown
**Title**: [Short, descriptive title]

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

**Acceptance Criteria**:
- Given... When... Then...
- Given... When... Then...

**Notes**: [Technical notes, wireframe links]

**Story Points**: [Estimate]

Definition of Ready (DoR)

Story is Ready when:

  • User story follows format (As a... I want... So that...)
  • Acceptance criteria are clear and testable
  • Story is independent of other stories in sprint
  • Story is small enough to complete in sprint
  • Technical approach discussed with team
  • Dependencies identified and resolved
  • Wireframes/designs available (if UI work)

Definition of Done (DoD)

Story is Done when:

  • All acceptance criteria met
  • Code peer reviewed
  • Unit tests written and passing
  • Integration tests passing
  • No critical bugs
  • Documentation updated
  • Deployed to staging
  • PO accepted

Agile Documentation Approach

Just Enough Documentation

Write documentation when:

  • Required for compliance/audit
  • Multiple teams need to understand
  • Complex business rules
  • Integration specifications
  • Knowledge needs to persist

Keep lean when:

  • Small team with good communication
  • Frequent face-to-face interaction
  • Simple, well-understood domain
  • Short project duration

Lightweight Artifacts

TraditionalAgile Alternative
100-page BRD1-page project brief + backlog
Detailed FRSUser stories + acceptance criteria
Use Case documentsAcceptance scenarios
Data dictionaryEntity definitions in stories
Test planAutomated tests + DoD

Living Documentation

  • Keep docs in version control (Git)
  • Update as requirements evolve
  • Use wikis (Lark, Notion, Confluence)
  • Automate where possible

Backlog Refinement

Purpose

  • Break down large stories
  • Add detail to upcoming stories
  • Clarify requirements
  • Estimate stories
  • Prioritize backlog

Cadence

  • 1-2 hours per week
  • 1-2 sprints ahead
  • Regular rhythm

Refinement Activities

Story Splitting:

  • By workflow step
  • By business rule
  • By data variation
  • By platform (iOS/Android)
  • By user role

Estimation:

  • Planning poker
  • Story points (Fibonacci)
  • T-shirt sizing
  • Relative sizing

Prioritization with PO:

  • Business value
  • Risk reduction
  • Dependencies
  • Technical debt

Story Mapping

What is Story Mapping?

Visual technique to organize user stories along the user journey.

Structure

code
Activities (top row)
    ↓
Tasks (second row)
    ↓
Details/Stories (lower rows, by priority)

Example: E-commerce Story Map

code
Browse Products → Add to Cart → Checkout → Order Tracking
     ↓              ↓             ↓            ↓
View catalog     Add item      Shipping      View status
Search products  Update qty    Payment       Track shipment
Filter/sort      Save for later Review order  Get notifications

MVP ─────────────────────────────────────────────────
View catalog     Add item      Shipping      View status
Search           Update qty    Payment

Release 2 ───────────────────────────────────────────
Filter/sort      Save for later Review order Track shipment

Hybrid Methodology

When to Use Hybrid

  • Large enterprise projects
  • Regulatory requirements
  • Fixed-scope contracts
  • Distributed teams
  • Mixed maturity levels

Hybrid Approach

Waterfall Elements:

  • Initial discovery/analysis phase
  • Formal BRD for approval
  • Architecture design upfront
  • Go-live planning

Agile Elements:

  • Iterative development
  • User stories and sprints
  • Continuous delivery
  • Sprint demos

Example Hybrid Flow

code
Discovery (2-4 weeks): Requirements, BRD, Architecture
    ↓
Sprint 0: Setup, detailed design, initial stories
    ↓
Sprints 1-N: Agile development
    ↓
UAT Sprint: User acceptance testing
    ↓
Go-live: Deployment, hypercare

Scaled Agile (SAFe Basics)

Hierarchy

  • Portfolio: Strategic initiatives
  • Program: Agile Release Train (ART)
  • Team: Scrum teams

Key Roles

  • Product Manager (portfolio)
  • Product Owner (team)
  • System Architect
  • Release Train Engineer

Key Events

  • PI Planning (Program Increment)
  • System Demo
  • Inspect & Adapt

Tools for Agile BA

Backlog Management

  • Jira
  • Azure DevOps
  • Trello
  • Lark Base

Documentation

  • Lark Docs
  • Notion
  • Confluence

Collaboration

  • Miro/FigJam (story mapping)
  • Figma (wireframes)
  • Lark Meetings

Best Practices

Communication

✅ Face-to-face over documentation ✅ Working software over comprehensive docs ✅ Daily standups for alignment ✅ Demo early and often

Requirements

✅ Embrace change ✅ Just-in-time elaboration ✅ Collaborative refinement ✅ Testable acceptance criteria

Documentation

✅ Write just enough ✅ Keep it current ✅ Make it accessible ✅ Automate when possible

Collaboration

✅ Work closely with PO ✅ Be available to team ✅ Facilitate, don't dictate ✅ Learn technical basics

Common Anti-Patterns

Big Design Up Front: Too much analysis before development ❌ Requirements Dumping: Writing stories without collaboration ❌ Absent BA: Not available during sprints ❌ Gold Plating: Over-documenting everything ❌ Scope Denial: Not adapting to changing requirements

References

  • Agile Manifesto
  • Scrum Guide
  • User Story Mapping (Jeff Patton)
  • SAFe Framework
  • Agile Extension to BABOK