Scrum Master

El Scrum Master es la persona responsable del flujo del equipo y la salud del sprint. En un SDLC AI-native, el Scrum Master opera un stack de facilitación, no un calendario de ceremonias, y mide el flujo con primitivas, no con percepciones.

Resumen ejecutivo

El Scrum Master convierte al sprint en un ciclo de aprendizaje en lugar de una cinta de entrega. En un SDLC AI-native, el Scrum Master trabaja dentro de la fase de Delivery con un conjunto fijo de primitivas: un agente flow-coach, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son ceremonias facilitadas con agendas basadas en datos, briefs de impedimentos con dueños y reportes de flujo sprint contra sprint que convierten las retrospectivas en experimentos medibles.

Rol y responsabilidades

Piensa en el Scrum Master como el jefe del equipo de pits en una carrera. Los ingenieros manejan el auto y el equipo diseña el motor, pero es el jefe del equipo de pits quien cronometra las paradas, lee los datos de las llantas y decide cuándo entrar. El piloto confía en la decisión porque está basada en telemetría, no en opinión. En un SDLC AI-native el Scrum Master es dueño de la telemetría del flujo.

Responsabilidades principales:

• Facilitar la planificación de sprint, los daily standups, las revisiones y las retrospectivas usando Azure Boards y GitHub Projects como fuente de verdad
• Mantener el burn-down del sprint preciso en GitHub Projects y reconciliarlo con Azure Boards diariamente
• Ejecutar retrospectivas basadas en datos de flujo, no en opiniones
• Mantener el log de impedimentos, escalar los bloqueos antiguos al Engineering Manager o al Project Manager
• Capacitar al equipo en límites de WIP, jalar en lugar de empujar y rebanar a vertical-delgado
• Colaborar con el Technical Lead en el alcance de spikes para trabajo incierto
• Operar el agente Flow Coach y los prompts /plan-sprint, /run-retro, /impediment-scan, /spike-scope

Jobs to be done

1. Como Scrum Master, quiero que la planificación del sprint esté basada en el throughput del sprint anterior, para que el equipo se comprometa a un alcance realista en lugar de uno aspiracional.
2. Como Scrum Master, quiero una agenda de retro que cite incidentes específicos, valores atípicos de flujo y picos de WIP, para que la conversación produzca experimentos y dueños.
3. Como Scrum Master, quiero que los impedimentos sean detectados automáticamente desde PRs estancados y elementos antiguos en Azure Boards, para que el daily standup no descubra nada nuevo.
4. Como Scrum Master, quiero spikes con alcance acotado en tiempo, metas de aprendizaje explícitas y una rúbrica de decisión, para que la investigación se convierta en decisiones.
5. Como Scrum Master, quiero límites de WIP a nivel de equipo aplicados con recordatorios suaves, para que el cambio de contexto sea visible.
6. Como Scrum Master, quiero que cada experimento de retro sea rastreado a lo largo de los sprints, para que la mejora continua sea una práctica medible.

Puntos de dolor antes de la era AI-native

1. Planificación basada en la memoria del último sprint. Sin un gráfico de throughput, el equipo debate la capacidad en puntos abstractos y se sobrecompromete en un 30 por ciento.
2. Retros que se convierten en terapia. Desahogarse es saludable, pero sin prompts basados en datos, el equipo no puede convertir sentimientos en experimentos.
3. Logs de impedimentos que crecen sin reducirse. Los bloqueos viejos se vuelven folklore del equipo. El Scrum Master escala solo cuando alguien se queja lo suficientemente fuerte.
4. Spikes que nunca terminan. Un spike iniciado para responder una pregunta se convierte en un proyecto de investigación abierto. Sin decisión, sin entregable.
5. Burn-downs dibujados a mano. El gráfico que todos miran se mantiene manualmente, así que está dos días desactualizado y silenciosamente ignorado.

Flujo diario AI-native

El Scrum Master opera un ciclo diario y semanal. El ciclo usa primitivas de GitHub Copilot dentro de Visual Studio Code, Claude Code en la terminal para síntesis de reportes, y Microsoft Teams vía el M365 Agents SDK para ceremonias asíncronas.

Setup de la mañana

1. Abrir Visual Studio Code en el repositorio team-ops. GitHub Copilot Chat carga el .github/instructions/scrum.instructions.md con alcance.
2. Invocar /impediment-scan. El agente Flow Coach llama al GitHub MCP para PRs estancados, al Azure DevOps MCP para elementos antiguos en Azure Boards, y muestra cualquier cosa que esté por encima del umbral de antigüedad.
3. Publicar el prompt del daily standup en el canal de Teams del equipo vía el M365 Agents SDK. El prompt incluye las anomalías de flujo de ayer, no una actualización por turnos.

Ejecución al mediodía

1. Liderar o asistir a ceremonias. Para la planificación del sprint, invocar /plan-sprint. El agente extrae el throughput del último sprint, el backlog actual de Azure Boards y GitHub Projects, y propone un rango de compromiso con bandas de confianza.
2. Capacitar a un miembro del equipo en un spike. Invocar /spike-scope <topic>. El agente devuelve un esquema acotado en tiempo con metas de aprendizaje, criterios de salida y una rúbrica de decisión.
3. Reconciliar el burn-down del sprint entre Azure Boards y GitHub Projects. Cualquier desviación se registra como una advertencia del hook.

Revisión al final de la tarde

1. Ejecutar una retrospectiva cuando esté programada. Invocar /run-retro. El agente sintetiza datos del sprint (throughput, lead time, tests inestables, conteo de incidentes) en un brief de retro con tres secciones: patrones de flujo observados, experimentos candidatos y dueños propuestos.
2. Actualizar el log de impedimentos. Cualquier impedimento mayor a siete días se escala al Engineering Manager mediante un mensaje de Teams.
3. Cerrar el día empujando el brief de retro y el log de impedimentos al repositorio team-ops. GitHub Actions los publica en la página de aterrizaje de Azure Static Web App del equipo.

Primitivas recomendadas

Agente

Agente	Archivo	Propósito
flow-coach	.github/agents/flow-coach.agent.md	Facilitar ceremonias de sprint, escanear impedimentos, dar alcance a spikes, sintetizar retros

El agente Flow Coach usa claude-sonnet-4-6 por defecto, con las herramientas read, search, grep, bash. Extrae contexto de los MCPs de GitHub, Azure DevOps y Microsoft 365 Agents SDK. El pensamiento extendido está deshabilitado porque las tareas de facilitación son iterativas, no de razonamiento profundo.

Slash prompts

Comando	Archivo	Propósito
/plan-sprint	.github/prompts/plan-sprint.prompt.md	Generar una propuesta de plan de sprint basada en el historial de throughput
/run-retro	.github/prompts/run-retro.prompt.md	Producir un brief de retro con observaciones respaldadas por datos y candidatos a experimentos
/impediment-scan	.github/prompts/impediment-scan.prompt.md	Detectar PRs estancados y elementos antiguos en Azure Boards en todo el equipo
/spike-scope	.github/prompts/spike-scope.prompt.md	Acotar un spike con time-box, metas de aprendizaje y rúbrica de decisión

Instrucciones con alcance

El applyTo con alcance mantiene el lenguaje de facilitación distinto del lenguaje de revisión técnica.

Alcance (applyTo)	Archivo	Propósito
team-ops/sprints/**	.github/instructions/scrum.instructions.md	Estructura de ceremonia, frases alineadas con la Scrum-Guide, distinción Agile no agile
team-ops/retros/**	.github/instructions/retros.instructions.md	Encuadre de retro, causa sistémica sobre culpa individual
team-ops/spikes/**	.github/instructions/spikes.instructions.md	Plantilla de spike, aplicación de time-box, rúbrica de decisión

Hooks

Los hooks son gobernanza de cero tokens para los artefactos de ceremonia.

• pre-commit: rechazar un plan de sprint que comprometa por encima de la banda de confianza del throughput
• post-commit: regenerar el JSON del burn-down siempre que cambie el alcance del sprint
• pre-push: validar que cada experimento de retro tenga un dueño nombrado y un sprint objetivo

MCPs validados

Cada MCP listado abajo está registrado en el catálogo de MCP. No referencies ningún MCP que no esté en el catálogo.

MCP	Estado	Uso en esta persona
GitHub MCP Server	Oficial	Leer tableros de Projects, runs de Actions y estado de PRs para la reconciliación del burn-down
Azure DevOps MCP Server	Oficial (Microsoft)	Leer y actualizar iteraciones de sprint, work items e impedimentos en Azure Boards
Azure MCP Server	Oficial (Microsoft)	Consultar Azure Monitor para conteos de incidentes que afectan el flujo del sprint
Microsoft Learn Docs MCP	Oficial	Sustentar la guía de facilitación en Microsoft Learn y GitHub Docs
Microsoft 365 Agents SDK MCP	Oficial (Microsoft)	Publicar prompts de ceremonias, escalamientos de impedimentos y briefs de retro en Teams

Ejemplos reales

Ejemplo 1: planificación de sprint con bandas de confianza

Entrada: El equipo está planificando el Sprint 47. Los últimos tres sprints completaron en promedio 38 puntos de historia, con una desviación estándar de 6.

Invocación: /plan-sprint.

Salida esperada:

1. Un compromiso propuesto de 34 a 42 puntos de historia con una nota de confianza.
2. Un slice de backlog priorizado desde Azure Boards, con dependencias marcadas contra la vista de salud arquitectónica en Azure Monitor.
3. Un borrador en team-ops/sprints/47/plan.md listo para revisión del equipo.
4. Un post de Teams vía el Microsoft 365 Agents SDK invitando al equipo a refinar el plan antes de la reunión de planificación.

Ejemplo 2: retro para un sprint con dos rollbacks

Entrada: El Sprint 46 tuvo dos rollbacks en producción, tres picos de tests inestables y un ingeniero de guardia durante dos fines de semana consecutivos.

Invocación: /run-retro.

Salida esperada:

1. Un brief de retro en team-ops/retros/46.md con patrones de flujo observados: cluster de rollbacks en el módulo de pagos, tests inestables en la suite de checkout, desbalance de guardias.
2. Tres experimentos candidatos: introducir un test de contrato pre-merge para pagos, poner en cuarentena los tests inestables de checkout, rotar guardias con un tope más estricto.
3. Cada experimento tiene un dueño y un sprint objetivo, aplicado por el hook pre-push.
4. Un work item de seguimiento en Azure Boards para cada experimento, creado automáticamente.

Anti-patrones

1. Facilitación solo por plantilla. Una plantilla de retro copiada y pegada sin datos produce insights genéricos. Mitigación: cada prompt cita métricas de flujo de GitHub y Azure Boards.
2. Logs de impedimentos que solo lee el Scrum Master. Los bloqueos son propiedad del equipo. Mitigación: /impediment-scan publica en el canal de Teams del equipo, no en una nota privada.
3. Spikes que se saltan la rúbrica de decisión. Un spike sin criterios de salida se convierte en investigación por investigación. Mitigación: /spike-scope se rehúsa a generar un spike sin rúbrica de decisión.
4. Burn-downs actualizados manualmente. Los gráficos manuales mienten. Mitigación: el JSON del burn-down se regenera mediante un hook post-commit.
5. Planificación bajo presión de compromiso. Comprometerse con la ambición del trimestre pasado en lugar del throughput del sprint pasado es deshonesto. Mitigación: el hook pre-commit rechaza compromisos por encima de la confianza.

KPIs y métricas de impacto

Métrica	Línea base (manual)	Meta (agéntica)	Medición
Precisión del compromiso del sprint	Más o menos 35 por ciento	Más o menos 10 por ciento	Puntos completados versus comprometidos
Tasa de finalización de experimentos de retro	20 por ciento	Más de 70 por ciento	Tracker de experimentos a lo largo de sprints
Antigüedad mediana de impedimentos	9 días	Menos de 3 días	Analítica del log de impedimentos
Adherencia al time-box de spikes	45 por ciento	Más de 90 por ciento	Auditoría de cierre de spikes
Tiempo de preparación de ceremonias por semana	6 horas	Menos de 2 horas	Log de tiempo a la agenda
Eficiencia de tokens	N/A	Menos de 150k tokens por semana	Reporte de uso de Copilot

Madurez en cuatro niveles

Nivel	Nombre	Marcadores
L1	Manual	Burn-down hecho a mano, retros de memoria, impedimentos en un canal lateral
L2	Asistido	GitHub Copilot Chat para redactar ceremonias, sin agente, herramientas mixtas para datos de flujo
L3	Aumentado	Agente Flow Coach, cuatro slash prompts, instrucciones con alcance, Azure Boards y GitHub Projects reconciliados
L4	Autónomo	Kit completo de primitivas, hooks aplicados, retros que producen experimentos rastreados, escalamiento de impedimentos automatizado, scorecard de madurez por encima del 80 por ciento

Integración con otras personas

• Con el Engineering Manager: salida de retro compartida, señales de attrition y burnout
• Con el Project Manager: el flujo del sprint alimenta la cadencia de status para stakeholders
• Con el Technical Lead: alcance de spikes para trabajo arquitectónico incierto
• Con el Developer: límites de WIP y cadencia de ceremonias
• Con el QA Engineer: cuarentena de tests inestables y metas de confiabilidad de tests
• Con el SRE: la carga de guardias y el conteo de incidentes informan la capacidad del sprint
• Con el Release Manager: ventanas de despliegue reconciliadas con los compromisos del sprint

Glosario

• Flujo: la tasa a la que el equipo convierte compromisos en trabajo mergeado y desplegado, con el WIP visible de extremo a extremo.
• Throughput: puntos o elementos completados por sprint, usados como estimador de capacidad.
• Burn-down: una vista de serie temporal del alcance restante del sprint; regenerada automáticamente.
• Impedimento: cualquier bloqueo externo o interno que impide al equipo completar el trabajo comprometido.
• Spike: una investigación acotada en tiempo con metas de aprendizaje explícitas y una rúbrica de decisión.
• Banda de confianza: el rango de más o menos sobre un compromiso de sprint, derivado de la varianza histórica del throughput.

Referencias

• Documentación de GitHub Projects — fuente autoritativa para tableros de Projects y automatización
• Documentación de Azure Boards — iteraciones de sprint, work items y dashboards en Azure DevOps
• Microsoft 365 Agents SDK — publicar prompts de ceremonias y briefs de retro en canales de Teams
• Documentación de GitHub Actions — programar trabajos de reconciliación para burn-downs y escaneos de impedimentos
• Investigación de métricas DORA — el fundamento empírico detrás de las métricas de flujo