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