Scrum Manager
Asistente personal de scrum para Azure DevOps, integrado en el chat de GitHub Copilot en VS Code.
Gestiona work items, planifica tu sprint, registra trabajo en batch y mantiene sincronizada la estructura de tu equipo (frentes, epicas, tags) sin salir del editor — todo a traves de lenguaje natural o comandos guiados.
Requisitos
- VS Code 1.100.0 o superior
- GitHub Copilot activo (licencia individual o empresarial)
- Azure DevOps accesible mediante:
- Cuenta Microsoft (OAuth — recomendado): usa la misma sesion que ya tienes en VS Code. Cero creacion manual de tokens.
- Personal Access Token (PAT — fallback): con permisos de
Work Items: Read & Write y Project and Team: Read. Util en organizaciones donde OAuth esta restringido.
Configuracion inicial
- Abre el panel de chat de Copilot (
Ctrl+Shift+I)
- Escribe
@scrum
- El asistente intenta OAuth con tu cuenta Microsoft automaticamente. Si falla u optas por PAT, te guia en 2 pasos:
- Paso 1: Pega tu PAT de Azure DevOps
- Paso 2: Pega la URL de tu proyecto o un work item de referencia
La URL se analiza para extraer organizacion, proyecto, equipo y area path en un solo paso. El PAT (si lo usas) se almacena en el llavero del sistema operativo.
Para actualizar credenciales o resetear la configuracion: @scrum /config reset o Ctrl+Shift+P > "Scrum Manager: Configure".
Comandos
Empezar
| Comando |
Descripcion |
/start [journey] |
Menu guiado de journeys segun el estado de tu workspace — el punto de entrada si no sabes por donde empezar |
Crear y registrar trabajo
| Comando |
Descripcion |
/create <descripcion> |
Crear un work item desde lenguaje natural con clasificacion automatica |
/catchup <narrativa> |
Registrar trabajo realizado y pendiente en batch — crea y actualiza items |
/split #<id> |
Dividir una historia grande en tareas hijas (3-7 items) |
Gestionar el sprint
| Comando |
Descripcion |
/prioridad <razon> [filtro: x] [ids: 1,2] [ref: #id] |
Cambio de prioridad: comenta, taggea y mueve items de tu sprint al backlog |
/desenfoque <descripcion> [effort: N] |
Registra trabajo no planeado bajo el contenedor Desenfoques del sprint |
/today |
Ver los work items asignados en el sprint actual |
/plan |
Analizar el sprint y recomendar prioridades para el dia |
/move #<id> <estado> |
Cambiar el estado de un work item (New, Active, Closed, Removed — el trabajo terminado se marca Closed; el equipo no usa "Resolved") |
/note #<id> <texto> |
Agregar un comentario de progreso a un work item |
/audit [estilo] |
Auditar completitud de los items del sprint (con estilo, agrega critica de redaccion) |
/estado |
Ver borradores/propuestas pendientes y la cache del sprint |
Modos de trabajo
| Comando |
Descripcion |
/daily |
Modo Daily/Standup: narra ayer/hoy/bloqueos y se refleja en el tablero (con pickup entre dias) |
/planning |
Modo Sprint Planning: grooming + compromiso de sprint; ofrece materializar el cronograma del sprint |
/modos · /modo off |
Listar los modos disponibles · salir del modo activo |
Estructura del backlog (Solucion ▸ Frente ▸ Epic ▸ items + Objetivos)
| Comando |
Descripcion |
/setup-q |
Bootstrap de un trimestre: pega (o conversa) un arbol Iniciativa▸Solucion▸Frente y se escribe a rules.yaml |
/fronts · /fronts add <NL> · /fronts add-solution <Sol>: <Frentes> @<Equipo> |
Administrar frentes; editor markdown sin args; list/save/reset/repair |
/iniciativa <NL> |
Flujo anclado al frente: reusa o crea la Epic del trimestre y, opcional, un Objetivo. /iniciativa parent <#id> fija el padre de epicas |
/objective add <NL> |
Crear un objetivo guiado (con bloque Detalle). Tambien progress/review y ciclo done/pause/resume/retarget/drop |
/objectives · /objectives open |
Listar objetivos · abrir el editor markdown de ida y vuelta |
/cronograma <id> · ver · open · crear-sprint |
Plan de trabajo por objetivo (ver seccion abajo) |
/po [frente] |
Dashboard Product Owner (read-only): equipo completo o rollup por frente |
/epics import <#id> |
Rastrear epicas existentes |
Configuracion y reglas
| Comando |
Descripcion |
/guidelines |
Ver las reglas de clasificacion activas (organizacion + personales) |
/rules |
Abrir rules.yaml en el editor |
/config · /config files |
Ver/actualizar la configuracion · abrir los archivos de configuracion del proyecto |
/remember <regla> |
Ensenar una regla personalizada para clasificacion |
/help [comando] |
Ver la referencia de comandos con ejemplos |
Lenguaje natural
Tambien puedes escribir directamente lo que necesitas — el agente entiende tu intencion:
@scrum que tengo pendiente?
@scrum como vamos en el sprint?
@scrum mueve el [#1234](https://github.com/cristian/scrum-manager/issues/1234) a Active
@scrum agrega una nota al item de migracion: termine la revision de codigo
@scrum por donde deberia empezar hoy?
El agente tambien puede crear y registrar items directamente en la conversacion:
@scrum necesito un task para configurar el pipeline de CI
→ El agente clasifica, propone un borrador, y lo crea cuando confirmes
@scrum esta semana termine la migracion del servicio de pagos y necesito configurar monitoring
→ El agente extrae los items, propone crear/actualizar, y ejecuta cuando confirmes
Como funciona /create
- Describes el trabajo en lenguaje natural
- El agente clasifica tipo (Bug, Task, User Story, Habilitador, Issue, etc.), asigna tags, story points y epic
- Muestra un borrador con indicadores de confianza
- Puedes editar cualquier campo conversacionalmente: "cambia el tipo a Task", "quita el tag backend"
- Confirmas y se crea en Azure DevOps
Como funciona /catchup
- Describes todo el trabajo que hiciste y lo que tienes pendiente en un solo mensaje
- El agente extrae items individuales, los clasifica, e infiere el estado (hecho, en progreso, pendiente)
- Matchea contra items existentes del sprint — propone actualizar los que ya existen y crear los nuevos
- Puedes editar la propuesta por numero: "cambia #2 a Task", "quita el item 3"
- Confirmas y se crean/actualizan todos en Azure DevOps
Reglas de clasificacion
La extension trae unas guias por defecto con 7 tipos de work item (Epic, User Story, Habilitador, Task, Bug, Issue, Mejoramiento continuo), escala de Story Points de 1-21, y convenciones de nombrado por tipo. Edita rules.yaml (con /rules) para adaptarlas al proceso de tu equipo.
Puntos clave del estandar por defecto:
- Titulo (HU/HA/Task/MC):
<Frente> - <Componente> - <Accion> — nunca el formato "Como [rol], quiero..." en el titulo. Bug: [Area] BUG: .... Issue: [Categoria] .... Epic: IA_<YYYYQ> | <Solucion> - <Frente> [- <Valor>].
- Descripcion de User Story (HU): usa la plantilla user-voice "Como [rol], quiero [objetivo], para [beneficio]" (INVEST + 3C) y requiere criterios de aceptacion.
- Descripcion de Habilitador (HA): NO usa esa voz de usuario (es exclusiva de la HU). Una HA se describe tecnicamente: nombra su subtipo (Exploracion / Infraestructura / Arquitectura / Cumplimiento) y la HU o capacidad que habilita. Tambien requiere criterios de aceptacion.
- Estimacion: HU/HA usan Story Points; Task y Mejoramiento continuo usan el campo Effort pero en la misma escala de Story Points (no horas).
- Estados: New, Active, Closed, Removed — el trabajo terminado se marca Closed (el equipo no usa "Resolved").
Usa /guidelines para ver todas las reglas activas y /remember para agregar tus preferencias personales.
Frentes de trabajo
Un frente representa un equipo, producto o linea de trabajo (por ejemplo: Nimbus, Agente Orquestador, PLC). Cada frente define defaults que se aplican automaticamente al crear items:
- Aliases — nombres alternativos (ej.
Flowly resuelve a Nimbus).
- Tags por defecto.
- Epica por defecto.
- Area path por defecto.
- Responsables por defecto.
Tienes tres formas de administrar frentes — elige la que mas se ajuste a tu flujo:
Editor markdown (recomendado para usuarios no-dev):
@scrum /fronts
Abre fronts.md con un template guiado. Edita, guarda el archivo, y pulsa Guardar frentes (o escribe @scrum /fronts save). El archivo se sincroniza a rules.yaml.
Inline con lenguaje natural:
@scrum /fronts add Nimbus, alias Flowly, tag front-nimbus, epico Nimbus Q2
El agente clasifica y muestra un borrador con confirmacion.
YAML directo: si prefieres editar rules.yaml a mano (abre con @scrum /guidelines para ver la ruta), /fronts reset regenera el archivo markdown desde ese estado.
Una vez registrados, /create identifica el frente automaticamente desde la narrativa y aplica sus defaults. Puedes forzar uno con --front Nimbus en la descripcion.
Un frente tambien puede llevar un detalle (descripcion / proposito / alcance) que se redacta de forma guiada y alimenta la descomposicion del cronograma como "contexto del frente".
Estructura del backlog y objetivos
El backlog se organiza en dos ejes que se cruzan en el Epic:
- Contencion (de arriba hacia abajo):
Solucion ▸ Frente ▸ Epic ▸ work-items. Los items heredan los defaults del frente y cuelgan de un Epic.
- Overlay de meta: un Objetivo selecciona epicas/items y mide
% de avance. Un Objetivo puede abarcar varias epicas (incluso de varios frentes). Un Epic no es un Objetivo.
Comandos para construir y conectar esa estructura:
/setup-q — arranca un trimestre completo: pega (o construye conversando) un arbol Iniciativa ▸ Solucion ▸ Frente y se persiste a rules.yaml, deduplicando contra lo existente./iniciativa <NL> — parte de un frente existente, reusa o crea su Epic del trimestre y, opcionalmente, envuelve un Objetivo. Flujo determinista (sin adivinar el frente)./objective add <NL> — crea un Objetivo guiado, con un bloque Detalle (objetivo / contexto / alcance / criterios). /objectives open abre un editor markdown de ida y vuelta. Ancla una epica con crear-ancla → confirmar-ancla (requisito para el cronograma)./po [frente] — dashboard del Product Owner (solo lectura): vista del equipo o rollup por frente.
Cronograma (plan de trabajo por objetivo)
/cronograma convierte un Objetivo en un plan de trabajo time-phased (cronograma.yaml) y luego lo materializa por sprint.
/cronograma <id-objetivo> — el LLM descompone el objetivo en tareas, las valida contra el backlog, las agenda segun la velocidad y deja una preview para confirmar. Sin id, lista los objetivos para elegir; la velocidad es opcional (usa el historico o asume un valor y lo avisa). Lee el detalle del frente + el detalle del objetivo para que la descomposicion sea sustancial y dentro de alcance./cronograma ver <id> — abre una vista full-width (documento markdown) con la tabla de tareas y un diagrama Gantt (Mermaid)./cronograma open / edit — editor de ida y vuelta: ajusta titulo/tipo/SP/sprint/estado en una tabla y guarda con Guardar cronograma editado./cronograma crear-sprint <id> — materializa las tareas planeadas para el sprint actual como work items reales en Azure DevOps (preview → confirmar; crea padre-antes-que-hijo bajo la epica ancla).
En el modo /planning, si el objetivo activo tiene cronograma, el asistente ofrece materializar el sprint con el mismo motor.
Flujo conectado (de la estructura a la ejecucion)
/setup-q estructura del trimestre (Iniciativa ▸ Solucion ▸ Frente)
│
├─ /iniciativa reusa/crea la Epic del frente (+ Objetivo opcional)
├─ /create items clasificados bajo el frente
│
├─ /objective define la meta y ancla una epica (crear-ancla)
│ │
│ └─ /cronograma descompone el objetivo → plan (ver/Gantt/editor)
│ │
│ └─ /planning · crear-sprint materializa el sprint en ADO
│
├─ /daily · /catchup refleja el avance diario en el tablero
└─ /po rollup de avance para el Product Owner
Licencia
GPL-3.0-or-later — ver LICENSE.
Copyright (C) 2026 Cristian Camilo Giraldo Mazo giraldo.0302@gmail.com
