CtrlK
BlogDocsLog inGet started
Tessl Logo

metodologia-roadmap-poc

Execution roadmap generator with sprint breakdown, prerequisites, gates, team/budget, and risk register. Use when the user asks to "create a roadmap", "plan a PoC", "build sprint plan", "execution timeline", or mentions "proof of concept", "MVP plan", "milestones", "sprint breakdown", "iteracion", "go/no-go".

The canonical home for this skill is metodologia-roadmap-poc in JaviMontano/mao-discovery-framework

SKILL.md
Quality
Evals
Security

Roadmap & PoC Execution Planning: Sprint-Level Delivery Architecture

Generates 4-8 week execution roadmaps with sprint-level planning, prerequisite validation, measurable go/no-go gate criteria, team composition, budget ranges, and risk registers.

Principio Rector

Un PoC sin kill criteria es un prototipo disfrazado de validacion. La planificacion de ejecucion no es un ejercicio de optimismo — es un acto de ingenieria donde cada sprint tiene entregables medibles, cada gate tiene criterios binarios (pasa/no pasa), y cada riesgo tiene un costo cuantificado.

Filosofia de Execution Planning

  1. Sprints with gates, not just demos. Cada gate existe para tomar una decision concreta: seguir, pivotar o parar. Si no hay criterio medible, no es un gate — es una reunion.
  2. Prerequisites before Sprint 1. El equipo mas talentoso del mundo no puede compensar un prerequisito bloqueado. Validar prerequisites en Week 0 es inversion; descubrirlos en Sprint 2 es desperdicio.
  3. Team + budget realistic from Day 1. Un roadmap con equipo indefinido y presupuesto "TBD" no es un plan — es una esperanza. FTE allocation y budget ranges son requisitos, no opcionales.

Inputs

The user provides a scope and duration as $ARGUMENTS. Parse $1 as the PoC/MVP scope, $2 as duration, $3 as team model.

Parameters:

  • {MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
    • piloto-auto: Auto para sprint breakdown y prerequisites, HITL para gate criteria y budget decisions.
    • desatendido: Cero interrupciones. Roadmap completo con supuestos documentados.
    • supervisado: Autonomo con checkpoint en gate criteria y risk register.
    • paso-a-paso: Confirma cada sprint plan, gate criterion, budget range, y risk mitigation.
  • {FORMATO}: markdown (default) | html | dual
  • {VARIANTE}: ejecutiva (~40% — S1 kickoff + S5 timeline + S6 gates) | tecnica (full 7 sections, default)
$ARGUMENTS format: [scope] [duration] [team-model]
Examples:
  "loan-origination PoC 4 weeks"           → scope=loan-origination, duration=4w, model=default
  "full MVP 8 weeks distributed team"       → scope=MVP, duration=8w, model=distributed
  "infrastructure migration 6 weeks"        → scope=infra, duration=6w, model=default
  • If scope missing → ask: "What is the PoC/MVP scope? (1-2 sentence description)"
  • If duration missing → default to 4 weeks (2 sprints)
  • Team model: "Provider+Client hybrid" unless specified otherwise

If reference materials exist, load them:

Read ${CLAUDE_SKILL_DIR}/references/roadmap-patterns.md

When to Use

  • Planning PoC or MVP execution with sprint-level detail
  • Defining prerequisites and readiness criteria before engagement starts
  • Building go/no-go gate criteria for phased delivery
  • Estimating team composition and budget ranges for proposals
  • Creating risk registers with quantified delay and cost impact

When NOT to Use

  • Strategic roadmap or multi-year transformation → metodologia-solution-roadmap
  • Cost estimation and commercial modeling → metodologia-cost-estimation, metodologia-commercial-model
  • Architecture design → metodologia-software-architecture, metodologia-solutions-architecture
  • Project portfolio management → metodologia-project-program-management

Delivery Structure: 7 Sections

S1: Pre-Service Kickoff (Week 0)

Day-by-day agenda:

ActivityOwnerDurationOutcomes
AS-IS Context SessionTech Lead + PM2hCurrent state documented
Definition of Done WorkshopProvider Lead + Stakeholders1.5hDoD approved
Provider Setup (parallel)Provider Ops3hInfrastructure ready
Client Provisioning (parallel)Client IT3hAccess & resources granted

Parallel Setup Grid — two columns:

  • Left: Provider responsibilities (VPN, workspace, tools, comms channels)
  • Right: Client responsibilities (infrastructure, access, sponsorship, support)

S2: Prerequisites Validation Table

9+ prerequisites with owner, status, deadline, blocker flag.

IDPrerequisiteStatusOwnerDeadlineBlocker
P1VPN / Dev environment access...IT...Yes
P2Source code repo & branch strategy...Dev Lead...Yes
P3CI/CD pipeline access...DevOps...Yes
P4Test environment provisioned...Infra...Yes
P5Stakeholder availability confirmed...PM...Yes
P6Architecture design approved...Architect...No
P7Data access / test data available...Data team...Yes
P8Security review scheduled...Security...No
P9Monitoring / alerting setup...DevOps...No

Status chips: Complete | In Progress | Blocked | Not Started

S3: Sprint Breakdown

Per sprint (2-week default):

Sprint N — [Target Feature/Capability]

  • Days 1-2: [Task] (Owner, deliverable)
  • Days 3-4: [Task] (Owner, deliverable)
  • Day 5: Demo prep & UAT session
  • Days 6-7: [Integration task] (Owner, deliverable)
  • Days 8-9: [Validation task] (Owner, deliverable)
  • Day 10: Sprint review + retrospective

Deliverables Checklist — each with specific, testable acceptance criteria.

S4: Team Composition & Budget

Team Structure:

  • Provider: [N] senior + [M] mid-level = [FTE] total
  • Client: [K] dedicated + [L] part-time = [FTE] total
  • Leads: Product, Tech, QA assignments
  • Steering committee: frequency & size

Budget Range (plus/minus 20%):

  • Services: $[X]
  • Infrastructure/tools: $[Y]
  • Contingency (15%): $[Z]
  • Total: $[Total]
  • Monthly burn rate: $[/month]

S5: Timeline Visualization

Week 0        Week 1-2        Week 3-4        Week 5+
PRE-SERVICE   SPRINT 1        SPRINT 2        STABILIZE
Kickoff       Foundation      Integration     Deploy

S6: Gate Criteria

Gate 0>1: Readiness to Sprint 1

  • Critical prerequisites (Blocker=Yes) complete or mitigated
  • Kickoff executed with stakeholder sign-off
  • DoD document approved
  • Team access & tools verified

Gate 1>2: Readiness to Sprint 2

  • Sprint 1 deliverables verified
  • Demo successful, no critical blockers
  • UAT feedback incorporated
  • Architecture approved for real integration

Gate 2>Production: Production Readiness

  • E2E flow validated in staging
  • Performance meets baseline
  • Security assessment passed
  • Deployment runbook approved
  • Support team trained & on-call

S7: Risk Register

Risk IDDescriptionProbabilityImpactDelay (days)Cost ImpactMitigationOwner
R1[Risk]H/M/LH/M/L[N]$[X][Plan][Who]

Top 5-6 risks. Every risk includes estimated delay (days) and cost impact ($). This forces trade-off decisions: is mitigation investment justified?

Assumptions & Limits

  • Requires completed architecture/design phase as input
  • Assumes 2-week sprint cycles (configurable based on team velocity)
  • Assumes Provider+Client hybrid team with weekly steering oversight
  • Budget estimates are plus/minus 20% ranges, not fixed commitments
  • Cannot account for unforeseeable external blockers (regulatory mandates, org restructuring)
  • Prerequisites marked Blocker=Yes must resolve before Week 1 or timeline shifts
  • Team composition assumes roles available on stated dates; hiring delays cascade downstream

Edge Cases

ScenarioAdaptation
No CI/CD infrastructureAdd 3-5 day setup task to Sprint 1
100% remote teamAdd 15% communication overhead to ceremony estimates
Waterfall reporting requiredMap each sprint to milestone gate; add formal gate documentation
Budget approved but team not hiredInsert 2-4 week recruitment phase before Week 0
Multiple time zones (>4h spread)Adjust ceremonies to UTC midpoint; record all sessions

Trade-offs

DimensionOption AOption BDecision Rule
Sprint length2 weeks (fast feedback, 5h/week ceremonies)3 weeks (less overhead, delayed detection)2 weeks for CI/CD teams; 3 weeks for teams <4 engineers
PoC scopeNarrow-deep (1 full flow)Broad-shallow (3 partial flows)Narrow-deep reduces risk; broad-shallow maximizes learning
Team capacityFixed (cost certainty)Elastic (flexibility)Fixed for PoC; elastic for long engagements
Pre-serviceFull 5-day kickoffLightweight 2-dayFull for new teams; lightweight for teams with prior engagement

Conditional Logic

IF team size <4 engineers → extend sprints to 3 weeks (reduce meeting-to-coding ratio)
IF critical prerequisite blocked at Week 0 → escalate with quantified delay cost ("Team waiting costs $X/day")
IF Sprint 1 gate fails → execute remediation sprint before Sprint 2 (skipping compounds defects)
IF budget >$500K → add PMO oversight and formal change control board
IF engagement >8 weeks → add mid-engagement retrospective and scope revalidation

Validation Gate

Before delivering roadmap:

  • 9+ prerequisites with status, deadline, and blocker flag
  • Each sprint has daily task allocation with owner and deliverable
  • Each deliverable has specific, testable acceptance criteria
  • Timeline shows 4+ milestones with critical path marked
  • Gates define measurable go/no-go conditions
  • Team composition shows FTE allocation with role clarity
  • Budget range is plus/minus 20% with breakdown and burn rate
  • Risk register has 5-6 risks with delay/cost estimates
  • Roadmap is immediately actionable — team can execute Day 1 without rework

Casos Borde

CasoEstrategia de Manejo
Prerequisito critico bloqueado en Week 0 sin resolucion a la vistaEscalar con costo cuantificado ("Equipo esperando cuesta $X/dia"); no iniciar Sprint 1 hasta resolucion; documentar impacto en timeline
Equipo menor a 4 ingenierosExtender sprints a 3 semanas para reducir ratio ceremonies/coding; ajustar expectativas de velocidad; reducir scope por sprint
Gate de Sprint 1 falla (entregables no cumplen criterios)Ejecutar sprint de remediacion antes de Sprint 2; no saltar adelante porque los defectos se acumulan; re-evaluar scope si persiste
Budget aprobado pero equipo no contratado aunInsertar fase de reclutamiento de 2-4 semanas antes de Week 0; ajustar timeline total; documentar riesgo de hiring delays

Decisiones y Trade-offs

DecisionAlternativa DescartadaJustificacion
Sprints de 2 semanas como defaultSprints de 3 semanas o 1 semana2 semanas balancea feedback rapido con overhead de ceremonies; 1 semana es demasiado overhead; 3 semanas retrasa deteccion de problemas
Prerequisites validados en Week 0 antes de Sprint 1Descubrir prerequisites durante ejecucionEl equipo mas talentoso no compensa un prerequisito bloqueado; descubrirlos en Sprint 2 es desperdicio puro
Budget ranges con +/-20% y burn rate mensualEstimaciones puntuales sin rangoLas estimaciones puntuales crean expectativas falsas de precision; los rangos comunican incertidumbre honestamente
Risk register con delay estimado en dias y cost impactLista de riesgos sin cuantificarSin cuantificacion, los riesgos no generan decisiones de mitigacion; con costo, el trade-off inversion-mitigacion vs costo-del-riesgo es explicito

Knowledge Graph

graph TD
    subgraph Core["Roadmap & PoC Core"]
        A[metodologia-roadmap-poc]
        A1[S1: Pre-Service Kickoff]
        A2[S2: Prerequisites Validation]
        A3[S3: Sprint Breakdown]
        A4[S4: Team & Budget]
        A5[S5: Timeline Visualization]
        A6[S6: Gate Criteria]
        A7[S7: Risk Register]
    end
    subgraph Inputs["Inputs"]
        I1[PoC/MVP Scope]
        I2[Duration Constraint]
        I3[Team Model]
        I4[Architecture/Design Phase Output]
    end
    subgraph Outputs["Outputs"]
        O1[Roadmap Document]
        O2[Gantt Chart]
        O3[Prerequisites Tracker]
        O4[Risk Register]
    end
    subgraph Related["Related Skills"]
        R1[metodologia-cost-estimation]
        R2[metodologia-commercial-model]
        R3[metodologia-solution-roadmap]
        R4[metodologia-discovery-handover]
    end
    I1 --> A
    I2 --> A
    I3 --> A
    I4 --> A
    A --> A1 --> A2 --> A3 --> A4 --> A5 --> A6 --> A7
    A --> O1
    A --> O2
    A --> O3
    A --> O4
    R1 --> A
    A --> R2
    R3 --- A
    A --> R4

Output Templates

Formato MD (default):

# Roadmap & PoC — {proyecto}
## Resumen Ejecutivo
> Duracion: N semanas. Sprints: M. Team: X FTEs. Budget range: $Y +/-20%.
## S1: Pre-Service Kickoff (Week 0)
| Actividad | Owner | Duracion | Outcomes |
## S2: Prerequisites
| ID | Prerequisite | Status | Owner | Deadline | Blocker |
## S3: Sprint Breakdown
### Sprint 1 — [Target]
[Day-by-day plan with owners and deliverables]
## S4-S7: [secciones completas]
## Timeline
```mermaid
gantt
    title PoC Roadmap
    ...
**Formato HTML (para kickoff con cliente):**

Header: Logo + proyecto + timeline visual Section 1: Timeline Overview (Gantt visual con milestones) Section 2: Prerequisites Status Board (cards con semaforo) Section 3: Sprint Plans (accordion expandible por sprint) Section 4: Team Composition (org chart visual) Section 5: Gate Criteria (checklist interactivo) Section 6: Risk Register (tabla con highlighting por severidad) Section 7: Budget Summary (breakdown visual) Footer: Attribution MetodologIA + proximos pasos

### HTML (bajo demanda)
- Filename: `{fase}_roadmap_poc_{cliente}_{WIP}.html`
- Estructura: HTML self-contained branded (Design System MetodologIA v5). Timeline visual tipo Timeline con Gantt interactivo, prerequisites status board con semáforo, sprint accordion expandible y gate criteria checklist. WCAG AA, responsive, print-ready.

### DOCX (bajo demanda)
- Filename: `{fase}_roadmap_poc_{cliente}_{WIP}.docx`
- Generado via python-docx con MetodologIA Design System v5. Portada, TOC automático, encabezados en Poppins (navy), cuerpo en Montserrat, acentos en gold. Tablas de prerequisites, sprint breakdown y risk register con zebra striping. Encabezados y pies de página con branding MetodologIA.

### XLSX (bajo demanda)
- Filename: `{fase}_roadmap_poc_{cliente}_{WIP}.xlsx`
- Generado via openpyxl con MetodologIA Design System v5. Encabezados con fondo navy y texto Poppins blanco, cuerpo en Montserrat, zebra striping en filas. Hojas: Prerequisites Tracker (ID, prerequisito, status, owner, deadline, blocker flag), Sprint Breakdown (sprint, día, tarea, owner, entregable, acceptance criteria), Risk Register (ID, descripción, probabilidad, impacto, delay días, cost impact, mitigación, owner), Team & Budget (rol, tipo, FTE, fase). Conditional formatting por status de prerequisitos y severidad de riesgos. Auto-filters en todas las hojas. Valores directos sin fórmulas.

### PPTX (bajo demanda)
- Filename: `{fase}_roadmap_poc_{cliente}_{WIP}.pptx`
- Generado via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, títulos en Poppins, cuerpo en Montserrat, acentos en gold. Máx 20 slides ejecutivo / 30 técnico. Notas del presentador con referencias de evidencia. Slides: Pre-Service Kickoff Agenda, Prerequisites Status Board, Timeline Visualization (Gantt), Sprint Breakdown, Team Composition, Gate Criteria, Risk Register, Budget Summary.

## Evaluacion

| Dimension | Peso | Criterio | Umbral Minimo |
|-----------|------|----------|---------------|
| Trigger Accuracy | 10% | El skill se activa ante prompts de roadmap, PoC, sprint plan, execution timeline, milestones | 7/10 |
| Completeness | 25% | 9+ prerequisites con status y blocker flag; sprints con task allocation diaria; gates con criterios medibles; budget con breakdown y burn rate | 7/10 |
| Clarity | 20% | Timeline muestra 4+ milestones con critical path; el equipo puede ejecutar Day 1 sin retrabajo; gates son binarios | 7/10 |
| Robustness | 20% | Edge cases cubiertos (prerequisito bloqueado, equipo chico, gate fails, budget sin equipo); conditional logic documentada | 7/10 |
| Efficiency | 10% | Variante ejecutiva vs tecnica correctamente aplicada; duracion de kickoff adaptada al contexto (full vs lightweight) | 7/10 |
| Value Density | 15% | Risk register con 5-6 riesgos cuantificados (delay days + cost impact); cada entregable tiene acceptance criteria testeable | 7/10 |

**Umbral minimo global: 7/10.** Si alguna dimension cae por debajo, el entregable requiere revision antes de entrega.

## Cross-References

- **metodologia-cost-estimation:** Cost estimation that feeds budget ranges in the roadmap
- **metodologia-commercial-model:** Commercial model that uses roadmap for pricing and delivery terms
- **metodologia-solution-roadmap:** Strategic multi-year roadmap where PoC roadmap is a tactical slice
- **metodologia-discovery-handover:** Handover document that references roadmap for execution planning

## Output Format Protocol

| Format | Default | Description |
|--------|---------|-------------|
| `markdown` | Yes | Rich Markdown + Mermaid diagrams (Gantt). Token-efficient. |
| `html` | On demand | Branded HTML (Design System). Visual impact. |
| `dual` | On demand | Both formats. |

Default output is Markdown with embedded Mermaid Gantt diagrams. HTML generation requires explicit `{FORMATO}=html` parameter.

## Output Artifact

**Primary:** `RP-01_Roadmap_PoC_{project}.md` (or `.html` if `{FORMATO}=html|dual`) — Pre-service kickoff, prerequisites validation, sprint breakdown, team composition, budget range, timeline, gate criteria, risk register.

**Secondary:** Gantt chart (Mermaid), parallel setup grid, prerequisites tracker, risk register spreadsheet.

---
**Autor:** Javier Montaño | **Ultima actualizacion:** 12 de marzo de 2026
Repository
JaviMontano/mao-pm-apex
Last updated
First committed

Canonical home

JaviMontano/mao-discovery-framework
In sync

since Aug 28, 2026

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.