Execution Burndown: MetodologIA Execution Model

Instruments the MetodologIA productivity model (1 FTE = 1 shippable feature/day) into burndown dashboards, velocity tracking, and completion projections. Operates at daily sprint level per developer.

Guiding Principle

What is not measured is not managed. What is not decomposed is not estimated.

The burndown is not a pressure tool — it is a visibility tool. It enables detecting deviations early (day 3, not month 3) and adjusting before the project goes off track.

Execution Philosophy

1. 1-day sprint. Each developer has 1 day to deliver 1 shippable feature. If they do not deliver, it is a signal — not a failure.
2. Onboarding is investment, not overhead. Sprint 1 produces 0.3 features, Sprint 2 produces 0.7, Sprint 3+ produces 1.0. This is NOT slowness — it is a planned learning curve.
3. Burndown is forecast, not deadline. The burndown slope projects completion date. If the slope diverges from the plan, scope or team is adjusted — not "squeezed".
4. Features ≤3 SP or they get decomposed. The model collapses with large features. The Feature Decomposition Checklist is a prerequisite.

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