Execution tracking with 1-day sprints per developer, burndown charts (Atlassian-style), velocity tracking using the MetodologIA productivity model (1 FTE = 1 shippable feature/day from Sprint 2). Sprint 1 = onboarding. Produces burndown dashboards, velocity reports, and completion projections. Use when dimensioning execution effort, tracking delivery velocity, creating burndown projections, or when "burndown", "velocity", "sprints diarios", "1 feature por día", or "tracking de ejecución" is mentioned.
From maonpx claudepluginhub javimontano/mao-discovery-frameworkThis skill is limited to using the following tools:
examples/README.mdexamples/sample-output.htmlexamples/sample-output.mdprompts/metaprompts.mdprompts/use-case-prompts.mdreferences/body-of-knowledge.mdreferences/knowledge-graph.mmdreferences/state-of-the-art.mdScans installed skills to extract principles shared across 2+ skills and distills them into rules by appending, revising, or creating rule files.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Provides guidance on returns authorization, receipt inspection, condition grading, disposition routing, refund processing, fraud detection, and warranty claims in e-commerce operations.
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.
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.
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.
| Parameter | Value |
|---|---|
| Team | {N} developers |
| Total features | {N} (post-decomposition, ≤3 SP) |
| Start date | {date} |
| Onboarding sprints | {N} days |
| Base productivity factor | 1.0 |
%%{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]
| Sprint (Day) | Planned Features | Delivered Features | Actual Velocity | Factor vs Plan | Status |
|---|---|---|---|---|---|
| Sprint 1 (D1-D5) | {N×0.3/day} | {actual} | {actual/plan} | {factor} | green/yellow/red |
| Sprint 2 (D6-D10) | {N×0.7/day} | {actual} | {actual/plan} | {factor} | green/yellow/red |
| Sprint 3+ (D11+) | {N×1.0/day} | {actual} | {actual/plan} | {factor} | green/yellow/red |
Semaphores: green ≥90% of plan, yellow 70-89%, red <70%
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%)
Early deviation signals:
If burndown diverges from plan:
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
| Decision | Enables | Constrains | When to Use |
|---|---|---|---|
| 1-day sprints | Maximum visibility, fast feedback | Higher ceremony overhead | Teams ≥3 developers, features well-decomposed |
| Weekly sprints | Less overhead | Delayed signal detection | Small teams (1-2), complex features |
| Factor 1.0 baseline | Simple, optimistic | May underestimate complex domains | Greenfield projects, well-known stack |
| Factor 0.7 baseline | Realistic for brownfield | More conservative estimate | Legacy modernization, unfamiliar stack |
| Caso Borde | Estrategia de Manejo |
|---|---|
| Features no descompuestas (>3 SP encontradas en backlog) | Detener la proyeccion. Ejecutar Feature Decomposition Checklist como prerequisito. Re-estimar despues de descomposicion. Documentar features bloqueantes. |
| Equipo con alta rotacion durante ejecucion (>20% turnover) | Ajustar factor de productividad: cada nuevo integrante reinicia en Sprint 1 (0.3). Recalcular proyeccion con equipo efectivo. Recomendar overlap de 1 semana con saliente. |
| Velocity real <50% del plan por mas de 5 dias consecutivos | Activar protocolo de escalacion: revisar impedimentos, dependencias bloqueantes, y complejidad subestimada. No asumir "el equipo se pondra al dia". Proponer scope adjustment o team adjustment inmediato. |
| Proyecto con >50% de features con dependencias externas | El modelo de 1 feature/dia/dev no aplica directamente. Separar features independientes de dependientes. Proyectar solo independientes con burndown; dependientes van a risk register con SLA de resolucion. |
| Decision | Justificacion | Alternativa Descartada |
|---|---|---|
| Sprints de 1 dia sobre sprints semanales | Visibilidad maxima: desviaciones se detectan en dia 3, no en semana 3. Feedback loop ultra-rapido. | Sprints semanales: menor ceremonia pero señal de desviacion tardada; proyectos cortos pierden semanas antes de detectar problemas. |
| Factor 1.0 como baseline (1 feature/dia/dev) | Simple, optimista, facil de comunicar. Funciona para greenfield con stack conocido. Se ajusta con factores si la realidad difiere. | Factores complejos por rol/seniority: mas preciso en teoria pero dificil de mantener y comunicar. |
| Ramp-up de 3 sprints (0.3 / 0.7 / 1.0) | Refleja curva de aprendizaje real. Sprint 1 es inversion, no overhead. Establece expectativas realistas desde el dia 1. | Sin ramp-up: sobreestima capacidad inicial; genera frustacion y metricas rojas en primeras semanas. |
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
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}
A-04_Execution_Burndown_{project}_{WIP}.htmlA-04_Execution_Burndown_{project}_{WIP}.docx{fase}_{entregable}_{cliente}_{WIP}.pptxFilename: 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 |
|---|---|---|---|
| Dimension | Peso | Criterio |
|---|---|---|
| Trigger Accuracy | 10% | Se activa ante solicitudes de burndown, velocity, tracking de ejecucion, proyeccion de completitud |
| Completeness | 25% | Incluye burndown chart, velocity dashboard, completion projection, risk signals, y ajustes |
| Clarity | 20% | Semaforos con umbrales definidos; proyecciones con nivel de confianza; signals con acciones concretas |
| Robustness | 20% | Maneja features no descompuestas, rotacion de equipo, velocity baja sostenida, dependencias externas |
| Efficiency | 10% | Genera dashboard completo con parametros minimos (proyecto + team size + backlog) |
| Value Density | 15% | Cada metrica tiene interpretacion y accion sugerida; cero datos sin contexto |
Umbral minimo: 7/10
metodologia-chart-roadmap — Produce el feature backlog que alimenta el burndownmetodologia-onboarding-playbook — Modelo de ramp-up (0.3/0.7/1.0) alineado con onboardingmetodologia-data-storytelling — Interpreta las metricas de velocity para audiencia ejecutivametodologia-poc-lab — Valida feasibility tecnica antes de comprometer backlogPrimary: A-04_Execution_Burndown_{project}.md