> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blitzy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SDLC Integration

> Guide to seamlessly integrating Blitzy into your existing sprint workflow, team roles, and development process

export const ImageWrapper = ({src, alt, caption, width = '100%'}) => <Frame caption={caption}>
    <img src={src} alt={alt} style={{
  width: width,
  display: 'block'
}} />
  </Frame>;

<Accordion title="Before You Start - Prerequisites" icon="flag-checkered">
  Ensure you have completed these prerequisites:

  * **Blitzy Account Setup** - Your team has active Blitzy accounts with appropriate licenses
  * **Repository Connected** - Your codebase is connected to Blitzy and successfully ingested (see [Codebase Ingestion](/prompt-engineering/ingestion))
  * **Team Access Configured** - Team members have been granted appropriate permissions based on their roles
  * **Initial Training** - Team members have completed the [Quickstart guide](/quickstart)
</Accordion>

## Introduction

Blitzy adapts to your team's needs with three flexible integration workflows. Whether you're accelerating standard sprint work, tackling large-scale refactors, or improving code quality, Blitzy fits seamlessly into your existing development process.

Choose the workflow that matches your current priority:

* **Standard Sprint Acceleration** - Take 1-2 week user stories and complete them faster
* **Parallel Large-Scale Projects** - Run major refactors or new initiatives alongside current work
* **Code Quality Improvements** - Add test suites, documentation, or apply architectural patterns

## Getting Started

Choose your workflow and follow the recommended first steps:

<Tabs>
  <Tab title="Sprint Acceleration">
    **Recommended for:** Regular incremental development work and user story delivery

    * **Simple user stories** - Single task user stories work well for full-stack features with small scope
    * **Complex user stories** - Use sequential subtask approach (see [Best Practices](#best-practices)) or confine to a single architectural layer (e.g., all frontend, all API, or all data layer)
    * Select a user story from your current sprint, break it into sequential subtasks (STORY-001 through STORY-00N)
    * Store subtask details in a `user-stories/` folder and execute in order
    * Run them through Blitzy as a cohesive body of work, one subtask at a time
  </Tab>

  <Tab title="Large-Scale Projects">
    **Recommended for:** Major refactors, migrations, or new initiatives

    * Identify a high-value initiative that requires significant capacity
    * Create a detailed technical specification (more detail than sprint work)
    * Launch the project and check in weekly while team continues sprint work
  </Tab>

  <Tab title="Code Quality">
    **Recommended for:** Technical debt, testing, documentation, and architectural improvements

    * Pick one high-value quality improvement (e.g., tests for your most critical module)
    * Start small: one module, one pattern application, or one documentation pass
    * Launch alongside your next sprint to prove it doesn't impact velocity
  </Tab>
</Tabs>

<Info>
  **Why this approach works:**

  * Easier validation with contained scope
  * More meaningful deliverables
  * Better understanding of Blitzy's capabilities at scale
  * Once comfortable, combine workflows (e.g., sprint work + quality improvements running in parallel)
</Info>

## Development Workflows

### Workflow Options

<AccordionGroup>
  <Accordion title="Workflow 1: Standard Sprint Acceleration" icon="gauge-high" defaultOpen>
    **Best For:** Regular incremental development work and user story delivery

    **Use Case:** You have a 1-2 week user story in your sprint backlog that you want to complete faster and with higher quality.

    **The Process** (see the Weekly Sprint Flow example below for a visual representation):

    1. **End of Week** - Project Lead creates prompts from user stories and launches Blitzy projects
    2. **Overnight/Weekend** - Blitzy generates \~80% of the implementation (zero developer time)
    3. **Following Week** - Developers review, refine final 20%, and deploy

    **Blitzy Impact:**

    * More tasks completed per sprint
    * Developers focus on code reviews and refinement, not building from scratch
    * Frees up time for technical debt or innovation work
  </Accordion>

  <Accordion title="Workflow 2: Parallel Large-Scale Projects" icon="layer-group">
    **Best For:** Major refactors, migrations, or new initiatives that would otherwise block the team

    **Use Case:** You have a large-scale project (multi-week or multi-month epic) that you want to run in parallel with your team's current sprint work without disrupting velocity.

    **The Process:**

    1. **Initial Setup** - Project Lead creates comprehensive technical specification for the large initiative
    2. **Ongoing Generation** - Blitzy works on the large project while team continues regular sprint work
    3. **Periodic Review** - Weekly or bi-weekly check-ins on generated code
    4. **Final Integration** - Team dedicates a sprint to final review, testing, and deployment

    **Blitzy Impact:**

    * Major initiatives that would be postponed indefinitely now get delivered
    * Epics that would take months complete in weeks
    * Team maintains current sprint commitments without disruption
  </Accordion>

  <Accordion title="Workflow 3: Code Quality Improvements" icon="code-branch">
    **Best For:** Technical debt, testing, documentation, and architectural improvements

    **Use Case:** You need to improve code quality, add test coverage, generate documentation, or apply architectural patterns consistently across your codebase.

    **The Process:**

    1. **Identify Quality Goals** - Define specific quality improvements (e.g., "increase test coverage to 80%", "add JSDoc to all public APIs")
    2. **Create Focused Prompts** - Break improvements into logical chunks (by module, feature, or pattern)
    3. **Launch Alongside Sprints** - Start Blitzy projects for quality improvements while team works on features
    4. **Asynchronous Review** - Developers review and merge quality improvements between feature work
    5. **Continuous Integration** - Make quality improvements a regular part of your workflow

    **Blitzy Impact:**

    * Quality improvements happen without taking sprint capacity
    * Test coverage increases from 40% → 80%+ in weeks
    * Documentation exists and stays current
    * Technical debt decreases continuously
  </Accordion>
</AccordionGroup>

### Example: Weekly Sprint Flow

Here's a visual example of how many teams integrate Blitzy into their sprint cadence. This pattern works particularly well for standard sprint acceleration (Workflow 1 above), but each workflow can be adapted to your team's schedule.

<ImageWrapper src="/images/sdlc-calendar.png" alt="Blitzy SDLC weekly sprint flow calendar" />

**Result: Ship features every week with the same predictable pattern**

Developers and their coding assistants focus on refinement, edge cases, and deployment instead of building from scratch.

### How to Execute Work with Blitzy

Blitzy supports two approaches for providing specifications:

**Option 1: Direct from Tickets**
Use your existing ticket system (Jira, Linear, etc.) as the source of requirements. Copy ticket details into Blitzy prompts.

**Option 2: Version-Controlled Specs (Recommended for Complex Epics)**
Store detailed specifications in your repository for better traceability and iteration.

<Accordion title="Example Workflow: Epic to Merged PRs" icon="clipboard-list">
  1. **Create Epic & Stories** - Break epic into stories following your company's standards
  2. **Document in Version Control** - Store each story in `epic-stories/` folder with requirements and technical specifications
  3. **Execute Stories** - Process stories in chunks based on dependencies (e.g., `epic-stories/STORY-001.md` through `STORY-009.md`):
     * **Build Prompt**: Reference the story file(s) as your prompt
     * **Generate & Approve AAP**: Review the Autonomous Agent Plan (AAP) - Blitzy's technical blueprint with implementation steps, file changes, and architecture decisions. Learn more in the [Agent Action Plan guide](/project-lifecycle/aap-review).
     * **Execute**: Generate code (parallel execution allowed for independent stories)
     * **Refine PR**: Iterate until approved
     * **Merge**: Complete chunk before continuing to next dependent stories
  4. **Result**: Complete epic with traceable story-by-story changes in version control
</Accordion>

### Who Does What

During the Blitzy process, team members will take on specific roles throughout the project lifecycle.

<AccordionGroup>
  <Accordion title="Project Lead" icon="user-tie">
    *Tech Lead, Senior Developer, or Engineering Manager*

    **Responsibilities:**

    * Creates prompts from tickets and user stories
    * Reviews and approves AAPs for technical accuracy
    * Coordinates the generation process and handoffs

    **Decision Authority:** Final approval on AAP before code generation

    **Maps to:** Tech Lead, Scrum Master (technical), or Senior Engineer
  </Accordion>

  <Accordion title="Developers" icon="code">
    *Individual Contributors*

    **Responsibilities:**

    * Review generated code for quality and correctness
    * Handle the final 20% refinement (edge cases, optimizations)
    * Write additional tests as needed
    * Deploy to production

    **Decision Authority:** Approve/reject generated code, request regeneration if needed

    **Maps to:** Software Engineers (all levels)
  </Accordion>

  <Accordion title="Product Manager (Optional)" icon="clipboard-check">
    *Recommended for complex features*

    **Responsibilities:**

    * Validates that AAPs align with business requirements
    * Ensures acceptance criteria are met in the plan

    **Decision Authority:** Business logic approval before code generation

    **Maps to:** Product Owner or Product Manager
  </Accordion>
</AccordionGroup>

## Best Practices

**Good Tickets Make Good Code**

* Write clear acceptance criteria
* Include specific technical requirements
* Define expected inputs and outputs
* Avoid vague goals like "improve performance"
* Follow your company's user story writing standards for consistency

**Epic Organization Strategies**

* **Single story epics** - Simple epics with one story; use the epic content directly as your prompt
* **Multi-story epics** - Complex epics broken into sequential stories (STORY-001 → STORY-002 → ...)
* **Vertical slices** - Each story within the epic should deliver a complete slice of functionality
* Store story details in version control (e.g., `epic-stories/` folder) alongside your codebase

<CardGroup cols={2}>
  <Card title="What Works Best" icon="check">
    - Epics that take a few weeks to a few months of effort
    - Epics broken into sequential, dependent stories
    - Work with clear, defined scope
    - Stories following your company's standards
  </Card>

  <Card title="What Doesn't Work" icon="xmark">
    * Tiny tasks (\< half day) - use Copilot instead
    * Mixing unrelated features in one project
    * Vague requirements without clear deliverables
    * Stories without clear sequential dependencies
  </Card>
</CardGroup>

## Technical Support

Blitzy provides AI Solution Consultants, and some contracts include Forward Deployed Engineers, to assist with:

* SDLC integration planning
* Team role definition and training
* Sprint workflow optimization
* Success metrics tracking
* Scaling Blitzy usage across teams

These resources can help customize this workflow to match your organization's specific SDLC processes and tooling.