Scale-Adaptive Planning

​

The Problem with Fixed Methodologies

Every change requires:
- Product requirements document
- Architecture review
- Epic breakdown
- Story creation
- Sprint planning
- Retrospective

Result: Bureaucracy for simple changes

Every change is ad-hoc:
- Jump straight to coding
- No planning or alignment
- Inconsistent approaches
- Integration conflicts

Result: Chaos for complex projects

​

Scale-Adaptive Planning in BMad

​

Quick Flow (1-15 Stories)

• Bug fixes and patches
• Small features with clear scope
• Refactoring existing code
• Prototyping and spikes
• Single-developer work

quick-spec → quick-dev
     ↓           ↓
 Tech-spec   Working code + tests

• tech-spec-{slug}.md — Single implementation document

• Planning: 15-30 minutes
• Implementation: Hours to 1-2 days

• Requirements fit in one conversation
• No architectural decisions needed
• Single agent can reason about full scope
• Existing architecture provides context

• “Fix the login timeout issue”
• “Add email validation to registration form”
• “Refactor authentication middleware”
• “Implement password reset flow”

​

BMad Method (10-50+ Stories)

• New products and platforms
• Complex features spanning multiple components
• Work requiring stakeholder alignment
• Projects needing architectural decisions

Phase 1 (Optional)     Phase 2            Phase 3               Phase 4
    ↓                     ↓                   ↓                     ↓
Product Brief  →  PRD + UX Design  →  Architecture + Epics  →  Sprint-by-sprint

• product-brief.md (optional) — Strategic vision
• PRD.md — Functional and non-functional requirements
• ux-spec.md (optional) — User experience design
• architecture.md — Technical decisions with ADRs
• Epic files with stories — Implementation breakdown
• project-context.md — Implementation rules

• Planning: 2-8 hours (spread across phases)
• Implementation: Days to weeks

• Requirements need discovery and alignment
• Architecture decisions affect implementation
• Multiple epics that could conflict
• Team needs shared context

• “Build a SaaS authentication platform”
• “Create a real-time collaboration feature”
• “Implement multi-tenant data isolation”
• “Add payment processing with multiple providers”

​

Enterprise (30+ Stories)

• Compliance-heavy systems (healthcare, finance)
• Multi-tenant platforms
• Security-critical applications
• Large-scale systems with complex integrations

Full BMad Method + Enterprise Extensions
         ↓
Additional artifacts:
- Security architecture
- Compliance mapping
- DevOps strategy
- Integration specifications
- Quality gates

• Everything from BMad Method PLUS:
• Security specifications
• Compliance documentation
• Integration contracts
• DevOps and deployment strategy
• Quality gate definitions

• Planning: 1-3 weeks
• Implementation: Weeks to months

• Regulatory compliance required
• Security reviews mandatory
• Multiple team coordination needed
• Long-term maintenance expected

• “HIPAA-compliant patient data system”
• “PCI-DSS payment processing platform”
• “SOC 2 Type II multi-tenant SaaS”
• “Government contract system with clearance requirements”

​

How BMad Adapts

​

Automatic Scope Detection

/bmad-bmm-quick-dev "Build a microservices architecture"

→ 🚨 SCOPE ALERT
  
  This request mentions:
  ✗ Multiple components (microservices)
  ✗ System-level architecture
  ✗ No existing specification
  
  Quick Flow is designed for small, focused changes.
  
  RECOMMENDATION: Use full BMad Method
  1. /bmad-bmm-create-prd for requirements
  2. /bmad-bmm-create-architecture for design
  3. /bmad-bmm-create-epics-and-stories for breakdown
  
  Proceed anyway? (Not recommended)

After discovery phase:

→ COMPLEXITY ASSESSMENT
  
  Based on our conversation, I'm detecting:
  ✓ 12 stories identified
  ✓ 3 architectural decisions needed
  ✓ Multiple team dependencies
  
  RECOMMENDATION: Escalate to full BMad Method
  
  This work is larger than Quick Flow can handle well.
  Would you like to:
  A) Create a PRD instead (recommended)
  B) Continue with Quick Flow (risk of rework)
  C) Split into smaller Quick Flow chunks

​

Manual Track Selection

/bmad-help "I have a SaaS idea with user auth, payments, and admin dashboard"

→ RECOMMENDATION: BMad Method track
  
  Your project includes:
  - Multiple major features (auth, payments, admin)
  - Likely 20-40 stories
  - Architecture decisions needed
  
  Suggested path:
  1. /bmad-bmm-create-product-brief (optional but recommended)
  2. /bmad-bmm-create-prd
  3. /bmad-bmm-create-architecture
  4. /bmad-bmm-create-epics-and-stories
  5. Implementation phase
  
  Want to start with Quick Flow instead?

• Run /bmad-bmm-quick-spec → Quick Flow track
• Run /bmad-bmm-create-prd → BMad Method track
• Install TEA module → Enterprise track option

​

Adaptation Mechanisms

​

1. Conditional Phases

​

2. Artifact Granularity

# tech-spec-auth-fix.md

## Problem
Login timeout after 30 seconds

## Solution
Increase timeout to 5 minutes, add keep-alive

## Tasks
1. Update AUTH_TIMEOUT constant (src/config.ts:12)
2. Add heartbeat endpoint (src/api/auth.ts)
3. Wire up keep-alive in client

## Acceptance Criteria
Given user is logged in
When idle for 4 minutes
Then session remains active

# PRD.md (20 pages)
## Vision
## User Personas
## Functional Requirements
## Non-Functional Requirements
## Success Metrics

# architecture.md (15 pages)  
## System Overview
## Component Design
## Data Models
## API Contracts
## ADRs (Architecture Decision Records)

# epic-01-authentication.md (5 pages)
## Epic Overview
## Stories (10 stories with full context)

​

3. Ceremony Level

• No sprint planning
• No retrospectives
• Minimal documentation
• Direct implementation

• Sprint planning (/bmad-bmm-sprint-planning)
• Story preparation (/bmad-bmm-create-story)
• Code review (/bmad-bmm-code-review)
• Epic retrospective (/bmad-bmm-retrospective)

• All BMad Method ceremonies PLUS:
• Security reviews
• Compliance checks
• Integration validation
• Quality gate approvals

​

4. Context Engineering

Context Sources:
- Tech-spec file
- project-context.md (if exists)
- Codebase scan

Context Sources:
- PRD (what and why)
- Architecture (how)
- Epic file (breakdown)
- Story file (specific context)
- project-context.md (rules)
- UX spec (flows)

All BMad Method sources PLUS:
- Security specifications
- Compliance requirements
- Integration contracts
- Quality gate definitions

​

Decision Framework

​

Size Indicators

• 1-5 stories → Quick Flow
• 5-15 stories → Quick Flow or BMad Method Simple
• 15-30 stories → BMad Method
• 30+ stories → BMad Method or Enterprise

• Hours to 1-2 days → Quick Flow
• 1-4 weeks → BMad Method
• 1+ months → BMad Method or Enterprise

• 1 developer → Quick Flow or BMad Method
• 2-5 developers → BMad Method
• 5+ developers → BMad Method or Enterprise

​

Complexity Indicators

• ✓ Requirements are clear and uncontested
• ✓ No architectural decisions needed
• ✓ Fits within existing patterns
• ✓ One developer can hold full scope
• ✓ No cross-team coordination required

• ✗ Requirements need discovery or alignment
• ✗ Architecture decisions affect implementation
• ✗ Multiple components or services involved
• ✗ Could be implemented inconsistently by different agents
• ✗ Stakeholders need documentation

• ✗ Compliance requirements (HIPAA, PCI-DSS, SOC 2)
• ✗ Security review mandatory
• ✗ Multi-tenant with data isolation concerns
• ✗ Integration with multiple external systems
• ✗ Long-term maintenance by multiple teams

​

Risk-Based Selection

• Internal tools
• Non-critical features
• Isolated changes
• Easy to revert

• User-facing features
• Data model changes
• API contracts
• Multi-component work

• Security-critical systems
• Financial transactions
• Healthcare data
• Compliance-regulated systems

​

Escalation and De-escalation

​

Escalating from Quick Flow

/bmad-bmm-quick-spec

[After discovery...]

→ ESCALATION RECOMMENDED
  
  This work involves:
  - 15 stories identified
  - Database schema changes
  - API contract modifications
  - 3 teams affected
  
  Your tech-spec work isn't wasted — it becomes input for the PRD.
  
  Switch to full BMad Method?
  A) Yes, create PRD (recommended)
  B) Continue with Quick Flow (not recommended)
  C) Split into smaller chunks

​

De-escalating from BMad Method

After PRD creation:

→ SIMPLIFICATION OPPORTUNITY
  
  Your PRD reveals:
  - 8 stories total
  - No architectural decisions needed
  - Single epic
  
  Consider Quick Flow instead:
  1. Convert PRD to tech-spec
  2. Run quick-dev
  
  Or continue with full method for practice/documentation.

​

Real-World Examples

​

Example 1: Bug Fix (Quick Flow)

/bmad-bmm-quick-dev "Fix double-submit on login form"

→ Barry: Got it. Scanning login form code...
         Found the issue: missing form.preventDefault()
         Adding preventDefault and submit debounce.
         Writing test. Done in 8 minutes.

​

Example 2: Feature Addition (BMad Method)

1. /bmad-bmm-create-prd → Define requirements, success metrics (1 hour)
2. /bmad-bmm-create-architecture → Decide payment abstraction layer, webhook handling (1.5 hours)
3. /bmad-bmm-create-epics-and-stories → Break into 4 epics, 22 stories (1 hour)
4. Implementation: 3 weeks of sprints

​

Example 3: Enterprise Platform (Enterprise)

1. Product Brief → Strategic vision and compliance landscape
2. PRD → Requirements including HIPAA-specific FRs/NFRs
3. Architecture → Security architecture, data encryption, audit logging
4. TEA Test Strategy → Risk-based testing, compliance validation
5. Epics & Stories → 60+ stories across 8 epics
6. Implementation with quality gates at each epic

​

Benefits of Scale-Adaptive Planning

​

1. Right-Sized Planning

• Simple changes stay simple
• Complex projects get proper foundation
• Planning effort matches risk

​

2. Reduced Waste

• Bug fixes don’t need PRDs
• Simple features don’t need architecture docs
• Save time without sacrificing quality

​

3. Consistency Where It Matters

• Multi-epic projects get architecture
• Single-component work stays lean
• Avoid integration problems

​

4. Learning Curve Management

• Begin with Quick Flow
• Graduate to BMad Method
• Adopt Enterprise when needed

​

5. Flexibility

• Start Quick Flow, escalate if scope grows
• Start BMad Method, simplify if scope shrinks
• Adapt mid-project

​

Next Steps

• Learn about Workflows — See how each track executes
• Explore Modules — Discover Enterprise extensions
• Understand Framework Overview — See the complete architecture
• Try the Getting Started Tutorial — Experience scale adaptation
• Read Quick Flow Explanation — Deep dive on the fast track