Execution Burndown: MetodologIA Execution Model

Inputs

Parse $1 as project name, $2 as team size (number of developers). Requires: feature backlog (decomposed, ≤3 SP each), team composition, start date. Optional: historical velocity data, complexity distribution, dependency map.

Delivery Structure

S1: Team & Backlog Setup

S2: Burndown Chart (Mermaid)

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#6366F1'}}}%%
xychart-beta
    title "Burndown — {project}"
    x-axis ["D1", "D2", "D3", "D4", "D5", "D10", "D15", "D20", "D25", "D30"]
    y-axis "Remaining features" 0 --> 200
    line "Plan" [200, 190, 180, 170, 160, 110, 60, 10, 0, 0]
    line "Actual" [200, 195, 185, 178, 168, 120, 75, 30, 5, 0]

S3: Velocity Dashboard

Semaphores: green ≥90% of plan, yellow 70-89%, red <70%

S4: Completion Projection

COMPLETION PROJECTION
═══════════════════════
Remaining backlog: {N} features
Current velocity: {V} features/day (team)
Planned velocity: {N_devs} features/day
Ratio: {V/N_devs × 100}%

Estimated date (actual): {date}
Estimated date (plan): {date}
Deviation: {+/- N} days

Confidence: HIGH (>85% plan) | MEDIUM (70-85%) | LOW (<70%)

S5: Risk Signals

Early deviation signals:

• Day 3: If velocity < 50% of plan → FLAG (may be normal onboarding)
• Day 5: If velocity < 70% of plan → ALERT (review impediments)
• Day 10: If velocity < 80% of plan → ESCALATION (adjust scope or team)
• Feature blocked >1 day: IMPEDIMENT — escalate immediately

S6: Adjustment Recommendations

If burndown diverges from plan:

1. Scope adjustment: Which features can be deferred? (MoSCoW reprioritization)
2. Team adjustment: Can 1 developer be added? (onboarding cost = 3-5 days)
3. Feature decomposition: Are there features >3 SP that slipped through? (re-decompose)
4. Impediment removal: What is blocking? (dependencies, environment, knowledge)

Ramp-up Model

Productivity per FTE:
  Sprint 1 (onboarding):  0.3 features/day
  Sprint 2 (ramp-up):     0.7 features/day
  Sprint 3+ (cruise):     1.0 features/day

Team productivity (N devs):
  Sprint 1:  N × 0.3 = {N×0.3} features/day
  Sprint 2:  N × 0.7 = {N×0.7} features/day
  Sprint 3+: N × 1.0 = {N} features/day

When to Use

• After roadmap defines feature backlog (Phase 4)
• When client asks "how long will it take?" or "how many developers do I need?"
• When tracking execution velocity during project delivery
• When projecting completion date from current velocity

When NOT to Use

• Discovery-only engagements (no execution phase)
• Research/exploration projects (features not decomposable)
• Projects with >50% unknowns (use spikes first)

Trade-off Matrix

Output Configuration

• Language: Spanish (Latin American, business register — simple, clear, concise, direct)
• Attribution: Expert committee of the MetodologIA Discovery Framework
• Tagline: "Construido por profesionales, potenciado por la red agéntica de MetodologIA."

Validation Gate

• All features decomposed to ≤3 SP
• Team size and composition documented
• Ramp-up curve specified (default or custom)
• Burndown chart generated with plan vs actual
• Velocity tracking per sprint
• Completion projection with confidence level
• Risk signals defined with thresholds

Supuestos y Limites

• Todas las features deben estar descompuestas a <=3 SP antes de usar esta skill.
• El modelo de productividad (1 FTE = 1 feature/dia) aplica desde Sprint 3. Sprints 1-2 tienen factores de ramp-up.
• NUNCA usar el burndown como herramienta de presion. Es una herramienta de visibilidad.
• NUNCA producir precios. Solo FTE-meses, magnitudes, cost drivers.

Casos Borde

Decisiones y Trade-offs

Knowledge Graph

graph TD
    subgraph Core["Core: Execution Burndown"]
        BURN[Burndown Chart]
        VEL[Velocity Tracking]
        PROJ[Completion Projection]
        SIGNAL[Risk Signals]
    end

    subgraph Inputs["Inputs"]
        BACKLOG[Feature Backlog <=3SP]
        TEAM[Team Size & Composition]
        DATE[Start Date]
        HIST[Historical Velocity]
    end

    subgraph Outputs["Outputs"]
        CHART[Burndown Dashboard]
        VELDASH[Velocity Dashboard]
        PROJREPORT[Projection Report]
        ADJUST[Adjustment Recommendations]
    end

    subgraph Related["Related Skills"]
        ROADMAP[chart-roadmap]
        ONBOARD[onboarding-playbook]
        DATASTORY[data-storytelling]
        POCLAB[poc-lab]
    end

    BACKLOG --> BURN
    TEAM --> VEL
    DATE --> PROJ
    HIST --> VEL
    BURN --> CHART
    VEL --> VELDASH
    PROJ --> PROJREPORT
    SIGNAL --> ADJUST
    ROADMAP --> BACKLOG
    ONBOARD --> VEL
    CHART --> DATASTORY
    POCLAB --> BACKLOG

Output Templates

Template 1: Execution Burndown Dashboard (Markdown)

Filename: A-04_Execution_Burndown_{project}_{WIP|Aprobado}.md

# Execution Burndown: {project}

## Parametros
| Parametro | Valor |
|---|---|
| Equipo | {N} developers |
| Total features | {N} (post-decomposition, <=3 SP) |
| Fecha inicio | {date} |
| Factor base | 1.0 |

## Burndown Chart
{Mermaid xychart-beta: plan vs actual}

## Velocity Dashboard
| Sprint | Planned | Delivered | Velocity | Factor | Status |
|---|---|---|---|---|---|

## Completion Projection
- Backlog restante: {N} features
- Velocity actual: {V} features/dia
- Fecha estimada: {date}
- Desviacion: {+/- N} dias
- Confianza: HIGH / MEDIUM / LOW

## Risk Signals
| Dia | Signal | Severidad | Accion Recomendada |
|---|---|---|---|

## Ajustes Recomendados
{Scope, team, decomposition, o impediment removal segun corresponda}

Template 3: HTML Dashboard (bajo demanda)

• Filename: A-04_Execution_Burndown_{project}_{WIP}.html
• Estructura: HTML self-contained branded (Design System MetodologIA v5). Timeline page con burndown chart interactivo (plan vs actual), velocity semáforo por sprint, y completion projection en tiempo real. WCAG AA, responsive, print-ready.

Template 4: DOCX Report (bajo demanda)

• Filename: A-04_Execution_Burndown_{project}_{WIP}.docx
• Generado con python-docx bajo MetodologIA Design System v5: portada, TOC automático, encabezados/pies de página con marca, tablas zebra, tipografía Poppins (headings navy), Montserrat (body), acentos dorados

Template 5: PPTX Dashboard (bajo demanda)

• Filename: {fase}_{entregable}_{cliente}_{WIP}.pptx
• Generado via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, títulos Poppins, cuerpo Montserrat, acentos dorados. Máx 20 slides ejecutivo / 30 técnico. Notas del orador con referencias de evidencia. Secciones: Team & Backlog Setup, Burndown Chart (plan vs actual), Velocity Dashboard por Sprint, Completion Projection, Risk Signals & Ajustes Recomendados.

Template 2: Velocity Report (XLSX-compatible Markdown)

Filename: Velocity_Report_{project}_{sprint}_{WIP|Aprobado}.md

# Velocity Report: {project} - Sprint {N}

## Resumen
| Metrica | Valor |
|---|---|
| Features planeadas | {N} |
| Features entregadas | {N} |
| Velocity ratio | {%} |
| Developers activos | {N} |
| Impedimentos | {N} |

## Detalle por Developer
| Developer | Planeadas | Entregadas | Bloqueadas | Notas |
|---|---|---|---|---|

## Tendencia de Velocity
{Mermaid xychart: velocity por sprint, ultimos 5 sprints}

## Impedimentos Activos
| Impedimento | Desde | Owner | ETA Resolucion |
|---|---|---|---|

Evaluacion

Umbral minimo: 7/10

Cross-References

• metodologia-chart-roadmap — Produce el feature backlog que alimenta el burndown
• metodologia-onboarding-playbook — Modelo de ramp-up (0.3/0.7/1.0) alineado con onboarding
• metodologia-data-storytelling — Interpreta las metricas de velocity para audiencia ejecutiva
• metodologia-poc-lab — Valida feasibility tecnica antes de comprometer backlog

Output Artifact

Primary: A-04_Execution_Burndown_{project}.md

Diagrams (Mermaid)

• xychart-beta: burndown (plan vs actual)
• Gantt: sprint timeline by developer