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

Aspect Traditional BA Agile BA

Documentation Comprehensive upfront Just enough, just in time

Requirements Complete before dev Emergent, evolving

Deliverables BRD, FRS, Use Cases User stories, acceptance criteria

Approach Waterfall/phases Iterative/incremental

Feedback End of project Continuous, each sprint

Change Formal change control Embrace 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:

Epic > Feature > User Story > Task

Example:

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

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

Traditional Agile Alternative

100-page BRD 1-page project brief + backlog

Detailed FRS User stories + acceptance criteria

Use Case documents Acceptance scenarios

Data dictionary Entity definitions in stories

Test plan Automated 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

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

Example: E-commerce Story Map

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

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