bmad-method 6.0.0-alpha.4 → 6.0.0-alpha.6

package/src/modules/bmm/docs/enterprise-agentic-development.md

@@ -1,20 +1,19 @@
 # Enterprise Agentic Development with BMad Method
 
-**Understanding the paradigm shift from traditional to AI-assisted team development**
+**The paradigm shift: From team-based story parallelism to individual epic ownership**
 
-**Reading Time:** ~25 minutes
+**Reading Time:** ~18 minutes
 
 ---
 
 ## Table of Contents
 
 - [The Paradigm Shift](#the-paradigm-shift)
-- [Traditional vs Agentic Development](#traditional-vs-agentic-development)
+- [The Evolving Role of Product Managers and UX Designers](#the-evolving-role-of-product-managers-and-ux-designers)
+- [How BMad Method Enables PM/UX Technical Evolution](#how-bmad-method-enables-pmux-technical-evolution)
 - [Team Collaboration Patterns](#team-collaboration-patterns)
 - [Work Distribution Strategies](#work-distribution-strategies)
-- [Enterprise Configuration](#enterprise-configuration)
-- [Git Submodule Approach](#git-submodule-approach)
-- [Team Workflows](#team-workflows)
+- [Enterprise Configuration with Git Submodules](#enterprise-configuration-with-git-submodules)
 - [Best Practices](#best-practices)
 - [Common Scenarios](#common-scenarios)
 
@@ -22,790 +21,528 @@
 
 ## The Paradigm Shift
 
-### Traditional Agile Development
+### Traditional Agile: Team-Based Story Parallelism
 
-In classic agile teams:
+- **Epic duration:** 4-12 weeks across multiple sprints
+- **Story duration:** 2-5 days per developer
+- **Team size:** 5-9 developers working on same epic
+- **Parallelization:** Multiple devs on stories within single epic
+- **Coordination:** Constant - daily standups, merge conflicts, integration overhead
 
-- **Epic duration:** Multiple sprints (4-12 weeks)
-- **Story duration:** 2-5 days per developer, sometimes 2 weeks
-- **Team size:** 5-9 developers per epic
-- **Parallelization:** Multiple developers work on stories within same epic
-- **Velocity:** 20-40 story points per 2-week sprint (team)
-- **Epic delivery:** Months for complex features
+**Example:** Payment Processing Epic
 
-### Agentic Development with BMM
+- Sprint 1-2: Backend API (Dev A)
+- Sprint 1-2: Frontend UI (Dev B)
+- Sprint 2-3: Testing (Dev C)
+- **Result:** 6-8 weeks, 3 developers, high coordination
 
-With AI-assisted development:
+### Agentic Development: Individual Epic Ownership
 
 - **Epic duration:** Hours to days (not weeks)
-- **Story duration:** 30 minutes to 4 hours per developer+agent
-- **Team size:** 1-2 developers can complete full epics
+- **Story duration:** 30 min to 4 hours with AI agent
+- **Team size:** 1 developer + AI agents completes full epics
 - **Parallelization:** Developers work on separate epics
-- **Velocity:** What took months now takes days
-- **Epic delivery:** Days for complex features, hours for simple ones
+- **Coordination:** Minimal - epic boundaries, async updates
+
+**Same Example:** Payment Processing Epic
+
+- Day 1 AM: Backend API stories (1 dev + agent, 3-4 stories)
+- Day 1 PM: Frontend UI stories (same dev + agent, 2-3 stories)
+- Day 2: Testing & deployment (same dev + agent, 2 stories)
+- **Result:** 1-2 days, 1 developer, minimal coordination
 
 ### The Core Difference
 
-**Traditional:** Stories are sized for human developers working alone
-**Agentic:** Stories are sized for human+AI collaboration, dramatically increasing throughput
+**What changed:** AI agents collapse story duration from days to hours, making **epic-level ownership** practical.
 
-**Result:** A single developer with AI agents can now complete in one day what previously required a full team and multiple sprints.
+**Impact:** Single developer with BMad Method can deliver in 1 day what previously required full team and multiple sprints.
 
 ---
 
-## Traditional vs Agentic Development
+## The Evolving Role of Product Managers and UX Designers
 
-### Story Complexity Comparison
+### The Future is Now
 
-**Traditional Agile Story (2-week duration):**
+Product Managers and UX Designers are undergoing **the most significant transformation since the creation of these disciplines**. The emergence of AI agents is creating a new breed of technical product leaders who translate vision directly into working code.
 
-```markdown
-## User Story: Add Payment Processing
+### From Spec Writers to Code Orchestrators
 
-As a user, I want to process payments so I can complete purchases.
+**Traditional PM/UX (Pre-2025):**
 
-### Tasks
+- Write PRDs, hand off to engineering
+- Wait weeks/months for implementation
+- Limited validation capabilities
+- Non-technical role, heavy on process
 
-- Research payment gateway options (2 days)
-- Design API integration (1 day)
-- Implement backend payment service (3 days)
-- Create frontend payment form (2 days)
-- Add validation and error handling (1 day)
-- Write unit tests (1 day)
-- Write integration tests (1 day)
-- Security review (1 day)
-
-**Estimate:** 10-12 days (2 weeks)
-```
+**Emerging PM/UX (2025+):**
 
-**BMM Agentic Story (2-4 hours):**
+- Write AI-optimized PRDs that **feed agentic pipelines directly**
+- Generate working prototypes in 10-15 minutes
+- Review pull requests from AI agents
+- Technical fluency is **table stakes**, not optional
+- Orchestrate cloud-based AI agent teams
 
-```markdown
-## Story 1: Implement Stripe Payment Backend API
+### Industry Research (November 2025)
 
-**Epic:** Payment Processing
-**Estimate:** 2h with AI agent
+- **56% of product professionals** cite AI/ML as top focus
+- **AI agents automating** customer discovery, PRD creation, status reporting
+- **PRD-to-Code automation** enables PMs to build and deploy apps in 10-15 minutes
+- **By 2026**: Roles converging into "Full-Stack Product Lead" (PM + Design + Engineering)
+- **Very high salaries** for AI agent PMs who orchestrate autonomous dev systems
 
-### Context
+### Required Skills for Modern PMs/UX
 
-- Use existing /api pattern
-- Follow auth middleware conventions
-- Integrate with Stripe SDK (already in package.json)
+1. **AI Prompt Engineering** - Writing PRDs AI agents can execute autonomously
+2. **Coding Literacy** - Understanding code structure, APIs, data flows (not production coding)
+3. **Agentic Workflow Design** - Orchestrating multi-agent systems (planning → design → dev)
+4. **Technical Architecture** - Reasoning frameworks, memory systems, tool integration
+5. **Data Literacy** - Interpreting model outputs, spotting trends, identifying gaps
+6. **Code Review** - Evaluating AI-generated PRs for correctness and vision alignment
 
-### Acceptance Criteria
+### What Remains Human
 
-- POST /api/payments/charge endpoint
-- Validation middleware
-- Error handling per API standards
-- Unit tests with 80%+ coverage
-```
+**AI Can't Replace:**
 
-The epic is broken into 6-8 small stories instead of 1 large story. Each story takes 2-4 hours instead of 2 weeks.
+- Product vision (market dynamics, customer pain, strategic positioning)
+- Empathy (deep user research, emotional intelligence, stakeholder management)
+- Creativity (novel problem-solving, disruptive thinking)
+- Judgment (prioritization decisions, trade-off analysis)
+- Ethics (responsible AI use, privacy, accessibility)
 
-### Epic Delivery Comparison
+**What Changes:**
 
-**Traditional Epic: "Payment Processing" (8-12 weeks)**
+- PMs/UX spend **more time on human elements** (AI handles routine execution)
+- Barrier between "thinking" and "building" collapses
+- Product leaders become **builder-thinkers**, not just spec writers
 
-- Sprint 1-2: Payment gateway research and design
-- Sprint 3-4: Backend implementation
-- Sprint 5-6: Frontend implementation
-- Sprint 7-8: Testing, security, deployment
-- **Team:** 3-5 developers
-- **Total:** 2-3 months
+### The Convergence
 
-**Agentic Epic: "Payment Processing" (1-3 days)**
+- **PMs learning to code** with GitHub Copilot, Cursor, v0
+- **UX designers generating code** with UXPin Merge, Figma-to-code tools
+- **Developers becoming orchestrators** reviewing AI output vs writing from scratch
 
-- Day 1 AM: Backend API stories (3-4 stories)
-- Day 1 PM: Frontend integration stories (2-3 stories)
-- Day 2: Testing, security validation (2-3 stories)
-- **Team:** 1-2 developers + AI agents
-- **Total:** 1-3 days
+**The Bottom Line:** By 2026, successful PMs/UX will fluently operate in both vision and execution. **BMad Method provides the structured framework to make this transition.**
 
 ---
 
-## Team Collaboration Patterns
+## How BMad Method Enables PM/UX Technical Evolution
 
-### Old Pattern: Stories as Work Units
+BMad Method is specifically designed to position PMs and UX designers for this future.
 
-**Traditional Agile:**
+### 1. AI-Executable PRD Generation
 
-```
-Epic: User Dashboard (8 weeks)
-├─ Story 1: Backend API (Dev A, Sprint 1-2)
-├─ Story 2: Frontend Layout (Dev B, Sprint 1-2)
-├─ Story 3: Data Visualization (Dev C, Sprint 2-3)
-├─ Story 4: User Preferences (Dev D, Sprint 3-4)
-└─ Story 5: Integration Testing (Team, Sprint 4)
+**PM Workflow:**
 
-Team: 4 developers working in parallel on stories within one epic
+```bash
+bmad pm *create-prd
 ```
 
-**Challenge:** Coordination overhead, merge conflicts, integration issues
+**BMad produces:**
 
-### New Pattern: Epics as Work Units
+- Structured, machine-readable requirements
+- Testable acceptance criteria per requirement
+- Clear epic/story decomposition
+- Technical context for AI agents
 
-**Agentic Development:**
+**Why it matters:** Traditional PRDs are human-readable prose. BMad PRDs are **AI-executable work packages**.
 
-```
-Project: Analytics Platform (2-3 weeks)
+**PM Value:** Write once, automatically translated into agent-ready stories. No engineering bottleneck for translation.
 
-Developer A:
-├─ Epic 1: User Dashboard (3 days, 12 stories)
-│   └─ Stories completed sequentially with AI agents
+### 2. Automated Epic/Story Breakdown
 
-Developer B:
-├─ Epic 2: Admin Panel (4 days, 15 stories)
-│   └─ Stories completed sequentially with AI agents
-
-Developer C:
-├─ Epic 3: Reporting Engine (5 days, 18 stories)
-│   └─ Stories completed sequentially with AI agents
+**PM Workflow:**
 
-Team: 3 developers working in parallel on separate epics
+```bash
+bmad pm *create-epics-and-stories
 ```
 
-**Benefits:** Minimal coordination, epic-level ownership, clear boundaries
-
----
-
-## Work Distribution Strategies
+**BMad produces:**
 
-### Strategy 1: Epic-Based Distribution (Recommended)
+- Epic files with clear objectives
+- Story files with acceptance criteria, context, technical guidance
+- Priority assignments (P0-P3)
+- Dependency mapping
 
-**Best for:** Teams of 2-10 developers
+**Why it matters:** Stories become **work packages for cloud AI agents**. Each story is self-contained with full context.
 
-**Approach:**
+**PM Value:** No more "story refinement sessions" with engineering. AI agents execute directly from BMad stories.
 
-- Each developer owns complete epics
-- Work sequentially through stories within epic
-- Parallel work happens at epic level
-
-**Example:**
-
-```yaml
-# sprint-status.yaml
-epics:
-  - id: epic-1
-    title: Payment Processing
-    owner: alice
-    status: in-progress
-    stories: 8
+### 3. Human-in-the-Loop Architecture
 
-  - id: epic-2
-    title: User Dashboard
-    owner: bob
-    status: in-progress
-    stories: 12
+**Architect/PM Workflow:**
 
-  - id: epic-3
-    title: Admin Panel
-    owner: carol
-    status: backlog
-    stories: 10
+```bash
+bmad architect *create-architecture
 ```
 
-**Benefits:**
-
-- Clear ownership and accountability
-- Minimal merge conflicts
-- Epic-level cohesion
-- Reduced coordination overhead
+**BMad produces:**
 
-### Strategy 2: Layer-Based Distribution
+- System architecture aligned with PRD
+- Architecture Decision Records (ADRs)
+- Epic-specific technical guidance
+- Integration patterns and standards
 
-**Best for:** Full-stack applications, teams with specialized skills
+**Why it matters:** PMs can **understand and validate** technical decisions. Architecture is conversational, not template-driven.
 
-**Approach:**
+**PM Value:** Technical fluency built through guided architecture process. PMs learn while creating.
 
-- Split epics by architectural layer
-- Frontend and backend as separate epics
-- Each developer owns their layer
+### 4. Cloud Agentic Pipeline (Emerging Pattern)
 
-**Example:**
+**Current State (2025):**
 
 ```
-Project: E-commerce Platform
-
-Frontend Developer:
-├─ Epic 1: Product Catalog UI (3 days)
-├─ Epic 3: Shopping Cart UI (2 days)
-└─ Epic 5: Checkout Flow UI (3 days)
-
-Backend Developer:
-├─ Epic 2: Product API (2 days)
-├─ Epic 4: Cart Service (2 days)
-└─ Epic 6: Payment Processing (3 days)
+PM writes BMad PRD
+   ↓
+create-epics-and-stories generates story queue
+   ↓
+Stories loaded by human developers + BMad agents
+   ↓
+Developers create PRs
+   ↓
+PM/Team reviews PRs
+   ↓
+Merge and deploy
 ```
 
-**Note:** This is abnormal in traditional agile (vertical slicing preferred), but works well in agentic development due to speed of delivery.
-
-**Benefits:**
-
-- Developers work in their expertise area
-- Can work truly in parallel
-- Clear API contracts between layers
-
-**Considerations:**
-
-- Requires clear API contracts upfront
-- Need integration testing coordination
-- Best with strong architecture phase
-
-### Strategy 3: Feature-Based Distribution
-
-**Best for:** Large teams (10+ developers), enterprise projects
-
-**Approach:**
-
-- Group related epics into features
-- Each developer/pod owns feature set
-- Features can span multiple subsystems
-
-**Example:**
+**Near Future (2026):**
 
 ```
-Feature Team A (2 devs): Payments & Billing
-├─ Epic 1: Payment Processing
-├─ Epic 2: Subscription Management
-├─ Epic 3: Invoice Generation
-└─ Epic 4: Billing Dashboard
-
-Feature Team B (2 devs): User Management
-├─ Epic 5: Authentication
-├─ Epic 6: Authorization
-├─ Epic 7: User Profiles
-└─ Epic 8: Account Settings
-
-Feature Team C (2 devs): Analytics
-├─ Epic 9: Event Tracking
-├─ Epic 10: Reporting Engine
-└─ Epic 11: Dashboard Widgets
+PM writes BMad PRD
+   ↓
+create-epics-and-stories generates story queue
+   ↓
+Stories automatically fed to cloud AI agent pool
+   ↓
+AI agents implement stories in parallel
+   ↓
+AI agents create pull requests
+   ↓
+PM/UX/Senior Devs review PRs
+   ↓
+Approved PRs auto-merge
+   ↓
+Continuous deployment to production
 ```
 
----
+**Time Savings:**
 
-## Enterprise Configuration
+- **Traditional:** PM writes spec → 2-4 weeks engineering → review → deploy (6-8 weeks)
+- **BMad Agentic:** PM writes PRD → AI agents implement → review PRs → deploy (2-5 days)
 
-### Challenge: Personalized BMM Content in Shared Repos
+### 5. UX Design Integration
 
-**Problem:**
-
-- Developers may customize agents, workflows, or configurations
-- Teams may use different methodologies (BMM, custom, other frameworks)
-- Organizations don't want personalized tooling committed to main repo
-- Different developers use different AI tools, MCPs, or agent systems
-
-**Anti-pattern (Don't do this):**
+**UX Designer Workflow:**
 
 ```bash
-# .gitignore approach - breaks many tools
-bmad/
-.claude/
+bmad ux *create-design
 ```
 
-**Issues with .gitignore:**
+**BMad produces:**
 
-- IDE tools lose track of context
-- Submodule management breaks
-- Team can't optionally share configurations
-- Hard to version control shared vs personal configs
+- Component-based design system
+- Interaction patterns aligned with tech stack
+- Accessibility guidelines
+- Responsive design specifications
 
-### Solution: Git Submodules
+**Why it matters:** Design specs become **implementation-ready** for AI agents. No "lost in translation" between design and dev.
 
-**Recommended approach:** Install BMM as a git submodule that each developer controls independently.
+**UX Value:** Designs validated through working prototypes, not static mocks. Technical understanding built through BMad workflows.
 
----
+### 6. PM Technical Skills Development
 
-## Git Submodule Approach
+**BMad teaches PMs technical skills through:**
 
-### Why Submodules?
+- **Conversational workflows** - No pre-requisite knowledge, learn by doing
+- **Architecture facilitation** - Understand system design through guided questions
+- **Story context assembly** - See how code patterns inform implementation
+- **Code review workflows** - Learn to evaluate code quality, patterns, standards
 
-**Benefits:**
+**Example:** PM runs `create-architecture` workflow:
 
-- BMM content exists in project but tracked separately
-- Each developer controls their own BMM version/configuration
-- Optional: Share team configurations via separate repo
-- IDE tools maintain proper context
-- Cleaner than .gitignore for this use case
+- BMad asks about scale, performance, integrations
+- PM answers business questions
+- BMad explains technical implications
+- PM learns architecture concepts while making decisions
 
-### Setup for New Projects
+**Result:** PMs gain **working technical knowledge** without formal CS education.
 
-**1. Create BMM submodule (optional team config repo):**
+### 7. Organizational Leverage
 
-```bash
-# In your organization
-git init bmm-config
-cd bmm-config
-npx bmad-method install
-# Customize for team standards
-git add .
-git commit -m "Initial BMM configuration for team"
-git push origin main
-```
+**Traditional Model:**
 
-**2. Add submodule to main project:**
+- 1 PM → supports 5-9 developers → delivers 1-2 features/quarter
 
-```bash
-# In your main project repo
-cd /path/to/your-project
+**BMad Agentic Model:**
 
-# Add BMM as submodule (using team config repo)
-git submodule add https://github.com/your-org/bmm-config.git bmad
+- 1 PM → writes BMad PRD → 20-50 AI agents execute stories in parallel → delivers 5-10 features/quarter
 
-# Or add as submodule (using official BMM)
-git submodule add https://github.com/bmad-code-org/BMAD-METHOD.git bmad
+**Leverage multiplier:** 5-10× with same PM headcount.
 
-# Commit submodule reference
-git add .gitmodules bmad
-git commit -m "Add BMM as submodule"
-```
+### 8. Quality Consistency
 
-**3. Team members clone and initialize:**
+**BMad ensures:**
 
-```bash
-# Clone main project
-git clone https://github.com/your-org/your-project.git
-cd your-project
+- AI agents follow architectural patterns consistently (via story-context)
+- Code standards applied uniformly (via epic-tech-context)
+- PRD traceability throughout implementation (via acceptance criteria)
+- No "telephone game" between PM, design, and dev
 
-# Initialize submodule
-git submodule update --init --recursive
+**PM Value:** What gets built **matches what was specified**, drastically reducing rework.
 
-# Each developer can now customize their bmad/ without affecting others
-cd bmad
-# Make personal customizations
-# These changes stay local unless pushed to submodule repo
-```
+### 9. Rapid Prototyping for Validation
 
-### Setup for Existing Projects
+**PM Workflow (with BMad + Cursor/v0):**
 
-**If BMM already installed directly:**
+1. Use BMad to generate PRD structure and requirements
+2. Extract key user flow from PRD
+3. Feed to Cursor/v0 with BMad context
+4. Working prototype in 10-15 minutes
+5. Validate with users **before** committing to full development
 
-```bash
-# 1. Backup existing BMM
-mv bmad bmad-backup
-
-# 2. Add as submodule
-git submodule add https://github.com/your-org/bmm-config.git bmad
-
-# 3. Restore customizations
-cp -r bmad-backup/bmad/_cfg/agents/*.customize.yaml bmad/bmad/_cfg/agents/
+**Traditional:** Months of development to validate idea
+**BMad Agentic:** Hours of development to validate idea
 
-# 4. Clean up
-rm -rf bmad-backup
+### 10. Career Path Evolution
 
-# 5. Commit
-git add .gitmodules bmad
-git commit -m "Convert BMM to submodule"
-```
+**BMad positions PMs for emerging roles:**
 
-### Submodule Workflow
+- **AI Agent Product Manager** - Orchestrate autonomous development systems
+- **Full-Stack Product Lead** - Oversee product, design, engineering with AI leverage
+- **Technical Product Strategist** - Bridge business vision and technical execution
 
-**Daily development:**
+**Hiring advantage:** PMs using BMad demonstrate:
 
-```bash
-# Work in main project - submodule is just there
-cd /path/to/your-project
-# BMM content available at ./bmad/
-# Load agents, run workflows normally
-```
+- Technical fluency (can read architecture, validate tech decisions)
+- AI-native workflows (structured requirements, agentic orchestration)
+- Results (ship 5-10× faster than peers)
 
-**Update personal BMM config:**
+---
 
-```bash
-cd bmad
-# Make changes to your personal config
-git add .
-git commit -m "Personal agent customizations"
-# Don't push unless sharing with team
-```
+## Team Collaboration Patterns
 
-**Update to latest team BMM config:**
+### Old Pattern: Story Parallelism
 
-```bash
-cd bmad
-git pull origin main
-cd ..
-git add bmad
-git commit -m "Update BMM to latest team config"
-```
-
-**Share configuration with team:**
+**Traditional Agile:**
 
-```bash
-cd bmad
-# Make team-beneficial changes
-git add .
-git commit -m "Add shared epic template for our domain"
-git push origin main
-# Tell team to update their submodules
 ```
+Epic: User Dashboard (8 weeks)
+├─ Story 1: Backend API (Dev A, Sprint 1-2)
+├─ Story 2: Frontend Layout (Dev B, Sprint 1-2)
+├─ Story 3: Data Viz (Dev C, Sprint 2-3)
+└─ Story 4: Integration Testing (Team, Sprint 3-4)
 
-### Team Configuration Sharing
-
-**Option 1: Fully Personal (No sharing)**
-
-```bash
-# Each developer's bmad/ is independent
-# No submodule repo - just local installation
-# Use .gitignore for bmad/ (acceptable here)
+Challenge: Coordination overhead, merge conflicts, integration issues
 ```
 
-**Option 2: Team Baseline + Personal Customization**
-
-```bash
-# Submodule repo has team standards
-# bmad/bmad/_cfg/agents/pm.customize.yaml (team)
-# Each dev adds personal customizations locally
-# Personal changes not pushed to submodule
-```
+### New Pattern: Epic Ownership
 
-**Option 3: Full Team Sharing**
+**Agentic Development:**
 
-```bash
-# All configurations in submodule repo
-# Team collaborates on agent improvements
-# Everyone pulls updates regularly
 ```
+Project: Analytics Platform (2-3 weeks)
 
-### Multi-Tool Teams
+Developer A:
+└─ Epic 1: User Dashboard (3 days, 12 stories sequentially with AI)
 
-**Scenario:** Team uses different AI tools (Claude Code, Cursor, Windsurf, custom)
+Developer B:
+└─ Epic 2: Admin Panel (4 days, 15 stories sequentially with AI)
 
-**Approach:**
+Developer C:
+└─ Epic 3: Reporting Engine (5 days, 18 stories sequentially with AI)
 
-```
-bmad/
-├─ bmad/_cfg/
-│   ├─ ides/
-│   │   ├─ claude-code.yaml (shared)
-│   │   ├─ cursor.yaml (shared)
-│   │   └─ windsurf.yaml (shared)
-│   └─ agents/
-│       ├─ pm.customize.yaml (personal - not in submodule)
-│       └─ architect.customize.yaml (personal - not in submodule)
-└─ .claude/
-    └─ commands/ (generated, IDE-specific)
+Benefit: Minimal coordination, epic-level ownership, clear boundaries
 ```
 
-**Each developer:**
-
-- Uses submodule for core BMM content
-- Personalizes IDE-specific configurations locally
-- Optionally shares improvements back to submodule
-
 ---
 
-## Team Workflows
+## Work Distribution Strategies
 
-### Workflow 1: Epic Assignment
+### Strategy 1: Epic-Based (Recommended)
 
-**Phase 2: Planning Complete**
+**Best for:** 2-10 developers
 
-```bash
-# After PRD + Architecture complete
-# Team lead or PM reviews epics
+**Approach:** Each developer owns complete epics, works sequentially through stories
 
-# sprint-status.yaml
+**Example:**
+
+```yaml
 epics:
   - id: epic-1
     title: Payment Processing
-    owner: unassigned
+    owner: alice
     stories: 8
+    estimate: 2 days
+
   - id: epic-2
     title: User Dashboard
-    owner: unassigned
+    owner: bob
     stories: 12
+    estimate: 3 days
 ```
 
-**Epic Assignment Meeting:**
+**Benefits:** Clear ownership, minimal conflicts, epic cohesion, reduced coordination
 
-1. Review epic scope and dependencies
-2. Assign epics to developers based on expertise/capacity
-3. Identify any epic dependencies (must be sequential)
-4. Update sprint-status.yaml with assignments
+### Strategy 2: Layer-Based
 
-**Result:**
+**Best for:** Full-stack apps, specialized teams
 
-```yaml
-epics:
-  - id: epic-1
-    title: Payment Processing
-    owner: alice
-    dependencies: []
+**Example:**
 
-  - id: epic-2
-    title: User Dashboard
-    owner: bob
-    dependencies: [epic-1] # Needs payment API
+```
+Frontend Dev: Epic 1 (Product Catalog UI), Epic 3 (Cart UI)
+Backend Dev: Epic 2 (Product API), Epic 4 (Cart Service)
 ```
 
-### Workflow 2: Daily Development
+**Benefits:** Developers in expertise area, true parallel work, clear API contracts
 
-**Developer's daily flow:**
+**Requirements:** Strong architecture phase, clear API contracts upfront
 
-```bash
-# 1. Check epic status
-cat docs/sprint-status.yaml
+### Strategy 3: Feature-Based
 
-# 2. Load SM agent, run epic-tech-context (if first story)
-# Creates epic-specific technical guidance
+**Best for:** Large teams (10+ developers)
 
-# 3. Load SM agent, run create-story
-# Creates next story in epic
+**Example:**
 
-# 4. Load SM agent, run story-context
-# Generates implementation context
+```
+Team A (2 devs): Payments feature (4 epics)
+Team B (2 devs): User Management feature (3 epics)
+Team C (2 devs): Analytics feature (3 epics)
+```
+
+**Benefits:** Feature team autonomy, domain expertise, scalable to large orgs
 
-# 5. Load DEV agent, run dev-story
-# Implement story (30min - 4hrs)
+---
 
-# 6. Load DEV agent, run code-review
-# Review implementation
+## Enterprise Configuration with Git Submodules
 
-# 7. Load SM agent, run story-done
-# Mark complete, advance queue
+### The Challenge
 
-# 8. Repeat steps 3-7 until epic complete
+**Problem:** Teams customize BMad (agents, workflows, configs) but don't want personal tooling in main repo.
 
-# 9. Load SM agent, run retrospective
-# Epic retrospective
-```
+**Anti-pattern:** Adding `bmad/` to `.gitignore` breaks IDE tools, submodule management.
 
-**Typical day for developer:**
+### The Solution: Git Submodules
 
-- Complete 3-8 stories (one epic, or partial epic)
-- Push code at epic boundaries or daily
-- Minimal coordination needed
+**Benefits:**
 
-### Workflow 3: Integration Points
+- BMad exists in project but tracked separately
+- Each developer controls their own BMad version/config
+- Optional team config sharing via submodule repo
+- IDE tools maintain proper context
 
-**When epics have dependencies:**
+### Setup (New Projects)
 
-**Epic 1 (Backend - Alice) complete:**
+**1. Create optional team config repo:**
 
 ```bash
-# Alice commits and pushes
-git add .
-git commit -m "feat: complete Payment Processing epic (epic-1)"
-git push origin feature/payment-processing
-
-# Updates team
-# "Epic 1 complete - payment API ready at /api/payments/*"
+git init bmm-config
+cd bmm-config
+npx bmad-method install
+# Customize for team standards
+git commit -m "Team BMM config"
+git push origin main
 ```
 
-**Epic 2 (Frontend - Bob) ready to start:**
+**2. Add submodule to project:**
 
 ```bash
-# Bob pulls latest
-git pull origin main  # After Alice's PR merged
-
-# Runs epic-tech-context with updated codebase
-# Context now includes Alice's payment API
-
-# Proceeds with stories
+cd /path/to/your-project
+git submodule add https://github.com/your-org/bmm-config.git bmad
+git commit -m "Add BMM as submodule"
 ```
 
-### Workflow 4: Code Review in Teams
+**3. Team members initialize:**
 
-**Two approaches:**
+```bash
+git clone https://github.com/your-org/your-project.git
+cd your-project
+git submodule update --init --recursive
+# Make personal customizations in bmad/
+```
 
-**Approach A: Epic-Level Review**
+### Daily Workflow
 
-- Developer completes entire epic
-- Opens PR for epic
-- Team reviews full epic implementation
-- Faster, maintains epic cohesion
+**Work in main project:**
 
-**Approach B: Story-Level Review**
+```bash
+cd /path/to/your-project
+# BMad available at ./bmad/, load agents normally
+```
 
-- Developer commits after each story
-- Opens PR per story or after N stories
-- More granular feedback
-- Better for learning teams
+**Update personal config:**
 
-**Recommended:** Epic-level review for experienced teams, story-level for learning teams.
+```bash
+cd bmad
+# Make changes, commit locally, don't push unless sharing
+```
 
----
+**Update to latest team config:**
 
-## Best Practices
+```bash
+cd bmad
+git pull origin main
+```
 
-### 1. Epic Ownership & Accountability
+### Configuration Strategies
 
-**Do:**
+**Option 1: Fully Personal** - No submodule, each dev installs independently, use `.gitignore`
 
-- Assign entire epic to one developer
-- Developer owns epic from context → stories → implementation → retrospective
-- Clear epic boundaries minimize conflicts
+**Option 2: Team Baseline + Personal** - Submodule has team standards, devs add personal customizations locally
 
-**Don't:**
+**Option 3: Full Team Sharing** - All configs in submodule, team collaborates on improvements
 
-- Split epic across multiple developers (coordination overhead)
-- Reassign epics mid-implementation (context loss)
+---
 
-### 2. Dependency Management
+## Best Practices
 
-**Do:**
+### 1. Epic Ownership
 
-- Identify epic dependencies in planning
-- Document required API contracts between dependent epics
-- Complete prerequisite epics before starting dependent ones
-- Use feature flags if parallel work needed
+- **Do:** Assign entire epic to one developer (context → implementation → retro)
+- **Don't:** Split epics across multiple developers (coordination overhead, context loss)
 
-**Don't:**
+### 2. Dependency Management
 
-- Assume epics are fully independent
-- Start dependent epic before prerequisite ready
-- Change API contracts without team coordination
+- **Do:** Identify epic dependencies in planning, document API contracts, complete prerequisites first
+- **Don't:** Start dependent epic before prerequisite ready, change API contracts without coordination
 
 ### 3. Communication Cadence
 
-**Traditional agile:** Daily standups essential for coordination
+**Traditional:** Daily standups essential
+**Agentic:** Lighter coordination
 
-**Agentic development:** Lighter coordination needed
+**Recommended:**
 
-**Recommended cadence:**
-
-- **Daily async updates:** "Epic 1, 60% complete, no blockers"
-- **Twice-weekly sync:** 15min check-in on progress/blockers
-- **Epic completion sync:** Brief demo, integration discussion
-- **Sprint retro:** After all epics complete
+- Daily async updates ("Epic 1, 60% complete, no blockers")
+- Twice-weekly 15min sync
+- Epic completion demos
+- Sprint retro after all epics complete
 
 ### 4. Branch Strategy
 
-**Feature branches per epic:**
-
 ```bash
-# Each developer works on epic branch
 feature/epic-1-payment-processing    (Alice)
 feature/epic-2-user-dashboard        (Bob)
 feature/epic-3-admin-panel           (Carol)
 
 # PR and merge when epic complete
-# Or: commit per story, PR at epic completion
 ```
 
-**Benefits:**
-
-- Clean separation of work
-- Easy to review epic as unit
-- Simple rollback if needed
-
 ### 5. Testing Strategy
 
-**Story-level:**
-
-- Unit tests per story (DoD requirement)
-- Agent writes tests during dev-story
-
-**Epic-level:**
-
-- Integration tests across epic stories
-- Create "Epic Integration Testing" story at epic end
-
-**Project-level:**
-
-- E2E tests after multiple epics complete
-- Can be separate epic: "E2E Test Suite"
+- **Story-level:** Unit tests (DoD requirement, written by agent during dev-story)
+- **Epic-level:** Integration tests across stories
+- **Project-level:** E2E tests after multiple epics complete
 
 ### 6. Documentation Updates
 
-**Real-time updates:**
-
-- `sprint-status.yaml` - Updated by story-done workflow
-- Story files - Updated by agents during implementation
-
-**Epic completion:**
-
-- Architecture docs - Update if epic changed architecture
-- API docs - Update if epic added/modified APIs
-- README - Update if epic affects setup/usage
-
-**Sprint completion:**
-
-- Retrospective insights incorporated
-- Lessons learned documented
-
-### 7. Submodule Maintenance
-
-**Weekly:**
-
-- Check for BMM updates (if using official as submodule)
-- Pull team configuration changes (if using team config)
-
-**Monthly:**
-
-- Review customizations (are they still needed?)
-- Share useful customizations with team
-- Clean up unused configurations
-
-**Per project:**
-
-- Initialize submodule for new team members
-- Document any project-specific BMM configurations
-
-### 8. Handling Conflicts
-
-**Scenario:** Two epics modify same file
-
-**Prevention:**
-
-- Architecture phase should identify shared code
-- Create "shared component" epic that runs first
-- Or: use feature flags and modular design
-
-**Resolution:**
-
-```bash
-# Epic 1 complete, merged to main
-# Epic 2 encounters conflict
-
-# Developer updates branch
-git checkout feature/epic-2
-git merge main
-# Resolve conflicts manually
-# Re-run affected story tests
-git add .
-git commit -m "Merge main, resolve conflicts"
-```
-
-### 9. Scaling to Large Teams
-
-**10-20 developers:**
-
-- Organize into feature pods (2-4 devs per pod)
-- Each pod owns related epics
-- Pod-level coordination, minimal cross-pod
-
-**20+ developers:**
-
-- Multiple product areas
-- Each area has own PRD, architecture
-- Areas can work fully independently
-- Quarterly integration points
-
-**100+ developers:**
-
-- Multiple products/services
-- Each uses BMM independently
-- Shared component teams provide APIs
-- Microservices architecture essential
+- **Real-time:** `sprint-status.yaml` updated by workflows
+- **Epic completion:** Update architecture docs, API docs, README if changed
+- **Sprint completion:** Incorporate retrospective insights
 
-### 10. Metrics & Velocity
+### 7. Metrics (Different from Traditional)
 
-**Track differently than traditional agile:**
-
-**Traditional metrics:**
-
-- Story points per sprint (team)
-- Velocity trends
-- Burndown charts
-
-**Agentic metrics:**
-
-- Epics per week (per developer)
-- Stories per day (per developer)
-- Time to epic completion
-- Code quality metrics (test coverage, review findings)
+**Traditional:** Story points per sprint, burndown charts
+**Agentic:** Epics per week, stories per day, time to epic completion
 
 **Example velocity:**
 
@@ -817,126 +554,51 @@ git commit -m "Merge main, resolve conflicts"
 
 ## Common Scenarios
 
-### Scenario 1: Startup (2-3 developers)
+### Scenario 1: Startup (2 Developers)
 
 **Project:** SaaS MVP (Level 3)
 
-**Team:**
-
-- Developer A (Full-stack, tech lead)
-- Developer B (Full-stack)
-
 **Distribution:**
 
 ```
 Developer A:
-├─ Epic 1: Authentication & User Management (3 days)
+├─ Epic 1: Authentication (3 days)
 ├─ Epic 3: Payment Integration (2 days)
 └─ Epic 5: Admin Dashboard (3 days)
 
 Developer B:
 ├─ Epic 2: Core Product Features (4 days)
-├─ Epic 4: Analytics & Reporting (3 days)
-└─ Epic 6: Notification System (2 days)
+├─ Epic 4: Analytics (3 days)
+└─ Epic 6: Notifications (2 days)
 
-Total: ~2 weeks with parallel work
-Traditional estimate: 3-4 months with same team
+Total: ~2 weeks
+Traditional estimate: 3-4 months
 ```
 
-**Coordination:**
-
-- Daily async Slack updates
-- Weekly 30min sync call
-- Epic completion demos
-- Shared docs/sprint-status.yaml in main repo
+**BMM Setup:** Direct installation, both use Claude Code, minimal customization
 
-**BMM Setup:**
+### Scenario 2: Mid-Size Team (8 Developers)
 
-- BMM installed directly (small team, shared approach)
-- Both use Claude Code
-- Minimal customization needed
-
----
-
-### Scenario 2: Mid-Size Team (8-10 developers)
-
-**Project:** Enterprise Platform Enhancement (Level 4)
-
-**Team:**
-
-- 2 Backend developers
-- 2 Frontend developers
-- 2 Full-stack developers
-- 1 DevOps engineer
-- 1 QA engineer (E2E testing epic)
+**Project:** Enterprise Platform (Level 4)
 
 **Distribution (Layer-Based):**
 
 ```
-Backend Team:
-Developer 1:
-├─ Epic 1: Payment Service API (3 days)
-├─ Epic 3: Subscription Service (3 days)
-└─ Epic 5: Webhook System (2 days)
-
-Developer 2:
-├─ Epic 2: User Management API (3 days)
-├─ Epic 4: Analytics API (3 days)
-└─ Epic 6: Admin API (2 days)
-
-Frontend Team:
-Developer 3:
-├─ Epic 7: Payment UI (2 days)
-├─ Epic 9: Subscription Dashboard (3 days)
-└─ Epic 11: User Settings (2 days)
-
-Developer 4:
-├─ Epic 8: Analytics Dashboard (3 days)
-├─ Epic 10: Admin Panel (3 days)
-└─ Epic 12: Notification Center (2 days)
-
-Full-Stack Team:
-Developer 5:
-├─ Epic 13: Real-time Features (4 days)
-└─ Epic 15: Search System (3 days)
-
-Developer 6:
-├─ Epic 14: Reporting Engine (4 days)
-└─ Epic 16: Export Functionality (3 days)
-
-DevOps:
-Developer 7:
-├─ Epic 17: CI/CD Pipeline (3 days)
-├─ Epic 18: Monitoring & Alerts (2 days)
-└─ Epic 19: Performance Optimization (3 days)
-
-QA:
-Developer 8:
-└─ Epic 20: E2E Test Suite (5 days, after others complete)
-
-Total: ~3 weeks with parallel work
-Traditional estimate: 9-12 months with same team
-```
+Backend (2 devs): 6 API epics
+Frontend (2 devs): 6 UI epics
+Full-stack (2 devs): 4 integration epics
+DevOps (1 dev): 3 infrastructure epics
+QA (1 dev): 1 E2E testing epic
 
-**Coordination:**
-
-- Bi-weekly sprint planning (epic assignment)
-- Async daily updates in Slack
-- Epic completion PRs reviewed by tech lead
-- Weekly integration testing
-
-**BMM Setup:**
-
-- Git submodule approach
-- Team config repo with shared baselines
-- Personal customizations local only
-- Mix of Claude Code, Cursor users
+Total: ~3 weeks
+Traditional estimate: 9-12 months
+```
 
----
+**BMM Setup:** Git submodule, team config repo, mix of Claude Code/Cursor users
 
-### Scenario 3: Large Enterprise (50+ developers)
+### Scenario 3: Large Enterprise (50+ Developers)
 
-**Project:** Multi-Product Platform (Multiple Level 4 projects)
+**Project:** Multi-Product Platform
 
 **Organization:**
 
@@ -947,94 +609,72 @@ Traditional estimate: 9-12 months with same team
 **Distribution (Feature-Based):**
 
 ```
-Product Team A: Payments Product
-├─ 10 epics across 8 developers
-└─ 2-week delivery
-
-Product Team B: User Management Product
-├─ 12 epics across 10 developers
-└─ 2-week delivery
+Product Team A: Payments (10 epics, 2 weeks)
+Product Team B: User Mgmt (12 epics, 2 weeks)
+Product Team C: Analytics (8 epics, 1.5 weeks)
+Product Team D: Admin Tools (10 epics, 2 weeks)
+Product Team E: Mobile (15 epics, 3 weeks)
 
-Product Team C: Analytics Product
-├─ 8 epics across 8 developers
-└─ 1.5-week delivery
+Platform Team: Shared Services (continuous)
+Infrastructure Team: DevOps (continuous)
 
-Product Team D: Admin Tools
-├─ 10 epics across 8 developers
-└─ 2-week delivery
-
-Product Team E: Mobile Apps
-├─ 15 epics across 10 developers
-└─ 3-week delivery
+Total: 3-4 months
+Traditional estimate: 2-3 years
+```
 
-Platform Team: Shared Services
-├─ 15 epics across 10 developers
-└─ Continuous delivery
+**BMM Setup:** Each team has own submodule config, org-wide base config, variety of IDE tools
 
-Infrastructure Team: DevOps & Platform
-├─ 8 epics across 5 developers
-└─ Continuous delivery
-```
+---
 
-**Coordination:**
+## Summary
 
-- Product teams work independently
-- Platform team provides APIs, runs 1 week ahead
-- Quarterly integration milestones
-- Automated testing & deployment
+### Key Transformation
 
-**BMM Setup:**
+**Work Unit Changed:**
 
-- Each team has own submodule config
-- Org-wide base configuration repo
-- Team-specific customizations in team repos
-- Variety of IDE tools (Claude Code, Cursor, Windsurf, VS Code + extensions)
+- **Old:** Story = unit of work assignment
+- **New:** Epic = unit of work assignment
 
-**Traditional estimate:** 2-3 years with same team size
-**Agentic delivery:** 3-4 months
+**Why:** AI agents collapse story duration (days → hours), making epic ownership practical.
 
----
+### Velocity Impact
 
-## Summary
+- **Traditional:** Months for epic delivery, heavy coordination
+- **Agentic:** Days for epic delivery, minimal coordination
+- **Result:** 10-50× productivity gains
 
-### Key Takeaways
+### PM/UX Evolution
 
-1. **Epics are the new stories** - Work distribution happens at epic level, not story level
-2. **Velocity transformation** - What took months now takes days
-3. **Team scaling** - Smaller teams can deliver enterprise-scale projects
-4. **Git submodules** - Best practice for enterprise BMM management
-5. **Reduced coordination** - Epic ownership minimizes coordination overhead
-6. **Layer splitting viable** - Frontend/backend epic splits work well at high velocity
-7. **Tool flexibility** - Teams can use different AI tools with same BMM foundation
+**BMad Method enables:**
 
-### The Bottom Line
+- PMs to write AI-executable PRDs
+- UX designers to validate through working prototypes
+- Technical fluency without CS degrees
+- Orchestration of cloud AI agent teams
+- Career evolution to Full-Stack Product Lead
 
-**Traditional Agile:**
+### Enterprise Adoption
 
-- Story = Unit of work assignment
-- Multiple developers per epic
-- Coordination intensive
-- Months for epic delivery
+**Git submodules:** Best practice for BMM management across teams
+**Team flexibility:** Mix of tools (Claude Code, Cursor, Windsurf) with shared BMM foundation
+**Scalable patterns:** Epic-based, layer-based, feature-based distribution strategies
 
-**Agentic Development:**
+### The Future (2026)
 
-- Epic = Unit of work assignment
-- One developer per epic
-- Minimal coordination
-- Days for epic delivery
+PMs write BMad PRDs → Stories auto-fed to cloud AI agents → Parallel implementation → Human review of PRs → Continuous deployment
 
-**Result:** Rethink team structure, work distribution, and coordination patterns for 10-50x productivity gains.
+**The future isn't AI replacing PMs—it's AI-augmented PMs becoming 10× more powerful.**
 
 ---
 
 ## Related Documentation
 
-- **[FAQ](./faq.md)** - Common questions
-- **[Scale Adaptive System](./scale-adaptive-system.md)** - Understanding project levels
-- **[Quick Start Guide](./quick-start.md)** - Getting started
-- **[Workflows Guide](../workflows/README.md)** - Complete workflow reference
-- **[Glossary](./glossary.md)** - Key terminology
+- [FAQ](./faq.md) - Common questions
+- [Scale Adaptive System](./scale-adaptive-system.md) - Project levels explained
+- [Quick Start Guide](./quick-start.md) - Getting started
+- [Workflow Documentation](./README.md#-workflow-guides) - Complete workflow reference
+- [Agents Guide](./agents-guide.md) - Understanding BMad agents
 
 ---
 
-_Agentic development fundamentally changes how we structure teams, distribute work, and coordinate efforts. Understanding these patterns is essential for enterprise success with BMM._
+_BMad Method fundamentally changes how PMs work, how teams structure work, and how products get built. Understanding these patterns is essential for enterprise success in the age of AI agents._