09 enablement · Delivery
Scrum MasterScrum MasterScrum Master
Flow, retros, sprint health.Fluxo, retros, saúde de sprint.Flujo, retros, salud de sprint.
The Scrum Master is the persona accountable for team flow and sprint health. In an AI-native SDLC, the Scrum Master operates a facilitation stack, not a ceremony schedule, and measures flow with primitives, not vibes.
Executive summary
The Scrum Master makes the sprint a learning loop rather than a delivery treadmill. In an AI-native SDLC, the Scrum Master works inside the Delivery phase with a fixed set of primitives: one flow-coach agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. The primary outputs are facilitated ceremonies with data-grounded agendas, impediment briefs with owners, and sprint-over-sprint flow reports that turn retrospectives into measurable experiments.
Role and responsibilities
Think of the Scrum Master like the pit crew chief at a race. The engineers drive the car and the team designs the engine, but it is the pit crew chief who times the stops, reads the tire data, and decides when to pull in. The driver trusts the call because it is grounded in telemetry, not opinion. In an AI-native SDLC the Scrum Master owns the telemetry of flow.
Primary responsibilities:
- Facilitate sprint planning, daily standups, reviews, and retrospectives using Azure Boards and GitHub Projects as the source of truth
- Keep the sprint burn-down accurate in GitHub Projects and reconcile with Azure Boards daily
- Run retrospectives grounded in flow data, not opinions
- Maintain the impediment log, escalate aging blockers to the Engineering Manager or Project Manager
- Coach the team on WIP limits, pull rather than push, and slice-to-thin-vertical
- Partner with the Technical Lead on spike scoping for uncertain work
- Operate the Flow Coach agent and the
/plan-sprint,/run-retro,/impediment-scan,/spike-scopeprompts
Jobs to be done
- As a Scrum Master, I want sprint planning grounded in last sprint’s throughput, so that the team commits to realistic scope instead of aspirational scope.
- As a Scrum Master, I want a retro agenda that cites specific incidents, flow outliers, and WIP spikes, so that the conversation yields experiments and owners.
- As a Scrum Master, I want impediments detected automatically from stalled PRs and aged Azure Boards items, so that the daily standup discovers nothing new.
- As a Scrum Master, I want spikes scoped with a time-box, explicit learning goals, and a decision rubric, so that research converts into decisions.
- As a Scrum Master, I want team-level WIP limits enforced with gentle reminders, so that context switching is visible.
- As a Scrum Master, I want every retro experiment tracked across sprints, so that continuous improvement is a measurable practice.
Pain points before AI-native
- Planning by last sprint’s memory. Without a throughput chart, the team debates capacity in abstract points and overcommits by 30 percent.
- Retros that turn into therapy. Venting is healthy, but without data-grounded prompts, the team cannot convert feelings into experiments.
- Impediment logs that grow without shrinking. Old blockers become team folklore. The Scrum Master escalates only when someone complains loudly enough.
- Spikes that never end. A spike started to answer a question becomes an open-ended research project. No decision, no deliverable.
- Burn-downs drawn by hand. The chart everyone looks at is maintained manually, so it is two days stale and quietly ignored.
AI-native daily workflow
The Scrum Master operates a daily and weekly loop. The loop uses GitHub Copilot primitives inside Visual Studio Code, Claude Code at the terminal for report synthesis, and Microsoft Teams via the M365 Agents SDK for async ceremonies.
Morning setup
- Open Visual Studio Code on the
team-opsrepository. GitHub Copilot Chat loads the scoped.github/instructions/scrum.instructions.md. - Invoke
/impediment-scan. The Flow Coach agent calls the GitHub MCP for stalled PRs, the Azure DevOps MCP for aged Azure Boards items, and surfaces anything over the staleness threshold. - Post the daily standup prompt in the team Teams channel via the M365 Agents SDK. The prompt includes yesterday’s flow anomalies, not a round-robin update.
Midday execution
- Lead or attend ceremonies. For sprint planning, invoke
/plan-sprint. The agent pulls last sprint’s throughput, the current backlog from Azure Boards and GitHub Projects, and proposes a commitment range with confidence bands. - Coach a team member through a spike. Invoke
/spike-scope <topic>. The agent returns a time-boxed outline with learning goals, exit criteria, and a decision rubric. - Reconcile the sprint burn-down between Azure Boards and GitHub Projects. Any drift is logged as a hook warning.
Afternoon review
- Run a retrospective when scheduled. Invoke
/run-retro. The agent synthesizes sprint data (throughput, lead time, flaky tests, incident count) into a retro brief with three sections: observed flow patterns, candidate experiments, proposed owners. - Update the impediment log. Any impediment older than seven days is escalated to the Engineering Manager via a Teams message.
- Close the day by pushing the retro brief and the impediment log to the
team-opsrepository. GitHub Actions publishes them to the team’s Azure Static Web App landing page.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
flow-coach | .github/agents/flow-coach.agent.md | Facilitate sprint ceremonies, scan for impediments, scope spikes, synthesize retros |
The Flow Coach agent uses claude-sonnet-4-6 by default, with tools read, search, grep, bash. It pulls context from GitHub, Azure DevOps, and Microsoft 365 Agents SDK MCPs. Extended thinking is disabled because facilitation tasks are iterative, not deep-reasoning.
Slash prompts
| Command | File | Purpose |
|---|---|---|
/plan-sprint | .github/prompts/plan-sprint.prompt.md | Generate a sprint plan proposal grounded in throughput history |
/run-retro | .github/prompts/run-retro.prompt.md | Produce a retro brief with data-backed observations and experiment candidates |
/impediment-scan | .github/prompts/impediment-scan.prompt.md | Detect stalled PRs and aged Azure Boards items across the team |
/spike-scope | .github/prompts/spike-scope.prompt.md | Scope a spike with time-box, learning goals, and decision rubric |
Instructions scoped
Scoped applyTo keeps facilitation language distinct from technical review language.
Scope (applyTo) | File | Purpose |
|---|---|---|
team-ops/sprints/** | .github/instructions/scrum.instructions.md | Ceremony structure, Scrum-Guide-aligned phrasing, Agile-not-agile distinction |
team-ops/retros/** | .github/instructions/retros.instructions.md | Retro framing, systemic-cause over individual-blame |
team-ops/spikes/** | .github/instructions/spikes.instructions.md | Spike template, time-box enforcement, decision rubric |
Hooks
Hooks are zero-token governance for ceremony artifacts.
pre-commit: reject a sprint plan that commits above the throughput confidence bandpost-commit: regenerate the burn-down JSON whenever sprint scope changespre-push: validate that every retro experiment has a named owner and a target sprint
Validated MCPs
Every MCP below is registered in the MCP catalog. Do not reference any MCP that is not in the catalog.
| MCP | Status | Use in this persona |
|---|---|---|
| GitHub MCP Server | Official | Read Projects boards, Actions runs, and PR state for burn-down reconciliation |
| Azure DevOps MCP Server | Official (Microsoft) | Read and update Azure Boards sprint iterations, work items, impediments |
| Azure MCP Server | Official (Microsoft) | Query Azure Monitor for incident counts that affect sprint flow |
| Microsoft Learn Docs MCP | Official | Ground facilitation guidance in Microsoft Learn and GitHub Docs |
| Microsoft 365 Agents SDK MCP | Official (Microsoft) | Post ceremony prompts, impediment escalations, and retro briefs into Teams |
Real examples
Example 1: sprint planning with confidence bands
Input: The team is planning Sprint 47. Last three sprints averaged 38 story points completed, with a standard deviation of 6.
Invocation: /plan-sprint.
Expected output:
- A proposed commitment of 34 to 42 story points with a confidence note.
- A ranked backlog slice from Azure Boards, with dependencies flagged against the architecture-health view in Azure Monitor.
- A draft in
team-ops/sprints/47/plan.mdready for the team review. - A Teams post via the Microsoft 365 Agents SDK inviting the team to refine the plan before the planning meeting.
Example 2: retro for a sprint with two rollbacks
Input: Sprint 46 had two production rollbacks, three flaky-test spikes, and one engineer on-call for two consecutive weekends.
Invocation: /run-retro.
Expected output:
- A retro brief in
team-ops/retros/46.mdwith observed flow patterns: rollback cluster in the payments module, flaky tests in the checkout suite, on-call imbalance. - Three candidate experiments: introduce a pre-merge contract test for payments, quarantine the flaky checkout tests, rotate on-call with a stricter cap.
- Each experiment has an owner and a target sprint, enforced by the pre-push hook.
- A follow-up Azure Boards work item for each experiment, created automatically.
Anti-patterns
- Facilitation by template alone. A copy-pasted retro template without data produces generic insights. Mitigation: every prompt cites flow metrics from GitHub and Azure Boards.
- Impediment logs that only the Scrum Master reads. Blockers are team property. Mitigation:
/impediment-scanposts to the team Teams channel, not a private note. - Spikes that skip the decision rubric. A spike without exit criteria becomes research-for-research. Mitigation:
/spike-scoperefuses to scaffold a spike without a decision rubric. - Burn-downs updated manually. Manual charts lie. Mitigation: the burn-down JSON is regenerated by a post-commit hook.
- Commitment-pressure planning. Committing to last quarter’s ambition instead of last sprint’s throughput is dishonest. Mitigation: the pre-commit hook rejects above-confidence commitments.
KPIs and impact metrics
| Metric | Baseline (manual) | Target (agentic) | Measurement |
|---|---|---|---|
| Sprint commitment accuracy | Plus or minus 35 percent | Plus or minus 10 percent | Completed versus committed points |
| Retro experiment completion rate | 20 percent | Over 70 percent | Experiment tracker across sprints |
| Impediment median age | 9 days | Under 3 days | Impediment log analytics |
| Spike time-box adherence | 45 percent | Over 90 percent | Spike closure audit |
| Ceremony prep time per week | 6 hours | Under 2 hours | Time-to-agenda log |
| Token efficiency | N/A | Under 150k tokens per week | Copilot usage report |
Maturity in four levels
| Level | Name | Markers |
|---|---|---|
| L1 | Manual | Handmade burn-down, retros from memory, impediments in a side channel |
| L2 | Assisted | GitHub Copilot Chat for drafting ceremonies, no agent, mixed tools for flow data |
| L3 | Augmented | Flow Coach agent, four slash prompts, scoped instructions, Azure Boards and GitHub Projects reconciled |
| L4 | Agentic | Full primitives kit, hooks enforced, retros producing tracked experiments, impediment escalation automated, maturity scorecard above 80 percent |
Integration with other personas
- With Engineering Manager: shared retro output, attrition and burnout signals
- With Project Manager: sprint flow feeds the stakeholder status cadence
- With Technical Lead: spike scoping for uncertain architectural work
- With Developer: WIP limits and ceremony cadence
- With QA Engineer: flaky-test quarantine and test-reliability goals
- With SRE: on-call load and incident count inform sprint capacity
- With Release Manager: deployment windows reconciled with sprint commitments
Glossary
- Flow: the rate at which the team converts commitments into merged, deployed work, with WIP visible end-to-end.
- Throughput: points or items completed per sprint, used as a capacity estimator.
- Burn-down: a time-series view of remaining sprint scope; regenerated automatically.
- Impediment: any external or internal blocker that prevents the team from completing committed work.
- Spike: a time-boxed investigation with explicit learning goals and a decision rubric.
- Confidence band: the plus-or-minus range on a sprint commitment, derived from historical throughput variance.
References
- GitHub Projects documentation — authoritative source for Projects boards and automation
- Azure Boards documentation — sprint iterations, work items, and dashboards on Azure DevOps
- Microsoft 365 Agents SDK — post ceremony prompts and retro briefs into Teams channels
- GitHub Actions documentation — schedule reconciliation jobs for burn-down and impediment scans
- DORA metrics research — the empirical foundation behind flow metrics
O Scrum Master é a persona responsável pelo fluxo do time e pela saúde do sprint. Em um SDLC AI-native, o Scrum Master opera uma pilha de facilitação, não um calendário de cerimônias, e mede fluxo com primitivas, não com feeling.
Resumo executivo
O Scrum Master transforma o sprint em um loop de aprendizado em vez de uma esteira de entrega. Em um SDLC AI-native, o Scrum Master trabalha dentro da fase de Delivery com um conjunto fixo de primitivas: um agente flow-coach, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são cerimônias facilitadas com agendas ancoradas em dados, briefs de impedimentos com donos e relatórios de fluxo sprint a sprint que transformam retrospectivas em experimentos mensuráveis.
Papel e responsabilidades
Pense no Scrum Master como o chefe dos boxes numa corrida. Os engenheiros dirigem o carro e o time projeta o motor, mas é o chefe dos boxes quem cronometra as paradas, lê os dados dos pneus e decide quando chamar para dentro. O piloto confia na decisão porque ela é ancorada em telemetria, não em opinião. Em um SDLC AI-native, o Scrum Master é dono da telemetria do fluxo.
Responsabilidades primárias:
- Facilitar sprint planning, dailys, reviews e retrospectivas usando Azure Boards e GitHub Projects como fonte da verdade
- Manter o burn-down do sprint acurado em GitHub Projects e reconciliar com Azure Boards diariamente
- Conduzir retrospectivas ancoradas em dados de fluxo, não em opiniões
- Manter o log de impedimentos, escalar bloqueios envelhecidos para o Engineering Manager ou Project Manager
- Fazer coaching do time em limites de WIP, pull em vez de push, e fatiar em vertical fino
- Fazer parceria com o Technical Lead no escopo de spikes para trabalho incerto
- Operar o agente Flow Coach e os prompts
/plan-sprint,/run-retro,/impediment-scan,/spike-scope
Jobs to be done
- Como Scrum Master, eu quero o sprint planning ancorado no throughput do último sprint, para que o time se comprometa com escopo realista em vez de aspiracional.
- Como Scrum Master, eu quero uma agenda de retro que cite incidentes específicos, outliers de fluxo e picos de WIP, para que a conversa gere experimentos e donos.
- Como Scrum Master, eu quero impedimentos detectados automaticamente a partir de PRs parados e itens envelhecidos no Azure Boards, para que a daily não descubra nada de novo.
- Como Scrum Master, eu quero spikes com escopo, time-box, metas explícitas de aprendizado e uma rubrica de decisão, para que pesquisa vire decisão.
- Como Scrum Master, eu quero limites de WIP em nível de time aplicados com lembretes gentis, para que troca de contexto fique visível.
- Como Scrum Master, eu quero cada experimento de retro rastreado entre sprints, para que melhoria contínua seja uma prática mensurável.
Dores antes da era AI-native
- Planejamento pela memória do último sprint. Sem um gráfico de throughput, o time debate capacidade em pontos abstratos e se compromete 30 por cento acima.
- Retros que viram terapia. Desabafar é saudável, mas sem prompts ancorados em dados, o time não converte sentimentos em experimentos.
- Logs de impedimento que crescem sem encolher. Bloqueios velhos viram folclore do time. O Scrum Master só escala quando alguém reclama alto o suficiente.
- Spikes que nunca acabam. Um spike iniciado para responder uma pergunta vira um projeto de pesquisa aberto. Sem decisão, sem entregável.
- Burn-downs desenhados à mão. O gráfico que todo mundo olha é mantido manualmente, então está dois dias desatualizado e silenciosamente ignorado.
Fluxo diário AI-native
O Scrum Master opera um loop diário e semanal. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code, Claude Code no terminal para síntese de relatórios e Microsoft Teams via M365 Agents SDK para cerimônias assíncronas.
Setup da manhã
- Abra o Visual Studio Code no repositório
team-ops. GitHub Copilot Chat carrega o.github/instructions/scrum.instructions.mdescopado. - Invoque
/impediment-scan. O agente Flow Coach chama o GitHub MCP para PRs parados, o Azure DevOps MCP para itens envelhecidos no Azure Boards e traz à tona qualquer coisa acima do limiar de staleness. - Poste o prompt da daily no canal do time no Teams via M365 Agents SDK. O prompt inclui as anomalias de fluxo de ontem, não um round-robin de updates.
Execução no meio do dia
- Conduza ou participe de cerimônias. Para sprint planning, invoque
/plan-sprint. O agente puxa o throughput do último sprint, o backlog atual do Azure Boards e GitHub Projects e propõe uma faixa de compromisso com bandas de confiança. - Faça coaching de um membro do time em um spike. Invoque
/spike-scope <tópico>. O agente retorna um outline com time-box, metas de aprendizado, critérios de saída e rubrica de decisão. - Reconcilie o burn-down do sprint entre Azure Boards e GitHub Projects. Qualquer deriva é registrada como hook warning.
Revisão no fim da tarde
- Conduza uma retrospectiva quando agendada. Invoque
/run-retro. O agente sintetiza dados do sprint (throughput, lead time, testes flaky, contagem de incidentes) em um brief de retro com três seções: padrões de fluxo observados, experimentos candidatos, donos propostos. - Atualize o log de impedimentos. Qualquer impedimento com mais de sete dias é escalado para o Engineering Manager via mensagem no Teams.
- Encerre o dia fazendo push do brief de retro e do log de impedimentos para o repositório
team-ops. GitHub Actions publica-os na landing page Azure Static Web App do time.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
flow-coach | .github/agents/flow-coach.agent.md | Facilitar cerimônias de sprint, escanear por impedimentos, escopar spikes, sintetizar retros |
O agente Flow Coach usa claude-sonnet-4-6 por padrão, com ferramentas read, search, grep, bash. Ele puxa contexto dos MCPs do GitHub, Azure DevOps e Microsoft 365 Agents SDK. Extended thinking fica desabilitado porque tarefas de facilitação são iterativas, não de raciocínio profundo.
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/plan-sprint | .github/prompts/plan-sprint.prompt.md | Gerar uma proposta de sprint plan ancorada no histórico de throughput |
/run-retro | .github/prompts/run-retro.prompt.md | Produzir um brief de retro com observações ancoradas em dados e experimentos candidatos |
/impediment-scan | .github/prompts/impediment-scan.prompt.md | Detectar PRs parados e itens envelhecidos do Azure Boards no time |
/spike-scope | .github/prompts/spike-scope.prompt.md | Escopar um spike com time-box, metas de aprendizado e rubrica de decisão |
Instruções escopadas
Um applyTo escopado mantém a linguagem de facilitação distinta da linguagem de review técnico.
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
team-ops/sprints/** | .github/instructions/scrum.instructions.md | Estrutura de cerimônia, fraseado alinhado ao Scrum Guide, distinção Agile-não-agile |
team-ops/retros/** | .github/instructions/retros.instructions.md | Framing de retro, causa sistêmica acima de culpa individual |
team-ops/spikes/** | .github/instructions/spikes.instructions.md | Template de spike, aplicação de time-box, rubrica de decisão |
Hooks
Hooks são governança de custo zero em tokens para artefatos de cerimônia.
pre-commit: rejeita um plano de sprint que se compromete acima da banda de confiança de throughputpost-commit: regenera o JSON do burn-down sempre que o escopo do sprint mudapre-push: valida que todo experimento de retro tenha um dono nomeado e um sprint-alvo
MCPs validados
Todos os MCPs abaixo estão registrados no catálogo de MCPs. Não referencie nenhum MCP que não esteja no catálogo.
| MCP | Status | Uso nesta persona |
|---|---|---|
| GitHub MCP Server | Oficial | Ler boards de Projects, runs do Actions e estado de PR para reconciliação de burn-down |
| Azure DevOps MCP Server | Oficial (Microsoft) | Ler e atualizar iterações de sprint, work items e impedimentos no Azure Boards |
| Azure MCP Server | Oficial (Microsoft) | Consultar Azure Monitor para contagens de incidente que afetam o fluxo do sprint |
| Microsoft Learn Docs MCP | Oficial | Ancorar guia de facilitação em Microsoft Learn e GitHub Docs |
| Microsoft 365 Agents SDK MCP | Oficial (Microsoft) | Postar prompts de cerimônia, escalações de impedimento e briefs de retro no Teams |
Exemplos reais
Exemplo 1: sprint planning com bandas de confiança
Entrada: O time está planejando o Sprint 47. Os últimos três sprints tiveram em média 38 story points concluídos, com desvio padrão de 6.
Invocação: /plan-sprint.
Saída esperada:
- Um compromisso proposto de 34 a 42 story points com uma nota de confiança.
- Uma fatia de backlog ranqueada do Azure Boards, com dependências sinalizadas contra a view de architecture-health no Azure Monitor.
- Um rascunho em
team-ops/sprints/47/plan.mdpronto para review do time. - Um post no Teams via Microsoft 365 Agents SDK convidando o time a refinar o plano antes da reunião de planning.
Exemplo 2: retro de um sprint com dois rollbacks
Entrada: O Sprint 46 teve dois rollbacks em produção, três picos de testes flaky e um engenheiro em on-call por dois finais de semana seguidos.
Invocação: /run-retro.
Saída esperada:
- Um brief de retro em
team-ops/retros/46.mdcom padrões de fluxo observados: cluster de rollback no módulo de pagamentos, testes flaky na suíte de checkout, desequilíbrio de on-call. - Três experimentos candidatos: introduzir um contract test pré-merge para pagamentos, colocar em quarentena os testes flaky de checkout, rodar on-call com cap mais estrito.
- Cada experimento tem um dono e um sprint-alvo, aplicados pelo hook pre-push.
- Um work item de follow-up no Azure Boards para cada experimento, criado automaticamente.
Anti-padrões
- Facilitação apenas por template. Um template de retro copiado sem dados produz insights genéricos. Mitigação: todo prompt cita métricas de fluxo do GitHub e Azure Boards.
- Logs de impedimento que só o Scrum Master lê. Bloqueios são propriedade do time. Mitigação:
/impediment-scanposta no canal do time no Teams, não em uma nota privada. - Spikes que pulam a rubrica de decisão. Um spike sem critérios de saída vira pesquisa-por-pesquisa. Mitigação:
/spike-scopese recusa a fazer scaffold de um spike sem rubrica de decisão. - Burn-downs atualizados manualmente. Gráficos manuais mentem. Mitigação: o JSON do burn-down é regenerado por hook post-commit.
- Planejamento por pressão de compromisso. Se comprometer com a ambição do último trimestre em vez do throughput do último sprint é desonesto. Mitigação: o hook pre-commit rejeita compromissos acima da confiança.
KPIs e métricas de impacto
| Métrica | Linha base (manual) | Meta (agentic) | Medição |
|---|---|---|---|
| Acurácia de compromisso do sprint | Mais ou menos 35 por cento | Mais ou menos 10 por cento | Pontos concluídos versus comprometidos |
| Taxa de conclusão de experimento de retro | 20 por cento | Acima de 70 por cento | Rastreador de experimentos entre sprints |
| Idade mediana de impedimento | 9 dias | Menos de 3 dias | Analytics do log de impedimentos |
| Aderência ao time-box de spike | 45 por cento | Acima de 90 por cento | Auditoria de fechamento de spike |
| Tempo de prep de cerimônia por semana | 6 horas | Menos de 2 horas | Log de time-to-agenda |
| Eficiência de tokens | N/A | Menos de 150k tokens por semana | Relatório de uso do Copilot |
Maturidade em quatro níveis
| Nível | Nome | Marcadores |
|---|---|---|
| L1 | Manual | Burn-down feito à mão, retros de memória, impedimentos em canal paralelo |
| L2 | Assistido | GitHub Copilot Chat para rascunho de cerimônias, sem agente, ferramentas misturadas para dados de fluxo |
| L3 | Aumentado | Agente Flow Coach, quatro slash prompts, instruções escopadas, Azure Boards e GitHub Projects reconciliados |
| L4 | Autônomo | Kit completo de primitivas, hooks aplicados, retros produzindo experimentos rastreados, escalação de impedimento automatizada, scorecard de maturidade acima de 80 por cento |
Integração com outras personas
- Com Engineering Manager: saída de retro compartilhada, sinais de attrition e burnout
- Com Project Manager: fluxo de sprint alimenta a cadência de status para stakeholders
- Com Technical Lead: escopo de spike para trabalho arquitetural incerto
- Com Developer: limites de WIP e cadência de cerimônia
- Com QA Engineer: quarentena de testes flaky e metas de confiabilidade de teste
- Com SRE: carga de on-call e contagem de incidentes informam capacidade de sprint
- Com Release Manager: janelas de deployment reconciliadas com compromissos de sprint
Glossário
- Fluxo: a taxa com que o time converte compromissos em trabalho merged e deployado, com WIP visível ponta a ponta.
- Throughput: pontos ou itens concluídos por sprint, usado como estimador de capacidade.
- Burn-down: uma view de série temporal do escopo restante do sprint; regenerada automaticamente.
- Impedimento: qualquer bloqueio externo ou interno que impeça o time de concluir o trabalho comprometido.
- Spike: uma investigação com time-box, metas explícitas de aprendizado e uma rubrica de decisão.
- Banda de confiança: a faixa mais-ou-menos em um compromisso de sprint, derivada da variância histórica de throughput.
Referências
- Documentação do GitHub Projects — fonte autoritativa para boards de Projects e automação
- Documentação do Azure Boards — iterações de sprint, work items e dashboards no Azure DevOps
- Microsoft 365 Agents SDK — postar prompts de cerimônia e briefs de retro em canais do Teams
- Documentação do GitHub Actions — agendar jobs de reconciliação para burn-down e scan de impedimentos
- Pesquisa de métricas DORA — a fundação empírica por trás das métricas de fluxo
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
- 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.
- 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.
- 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.
- 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.
- Como Scrum Master, quiero límites de WIP a nivel de equipo aplicados con recordatorios suaves, para que el cambio de contexto sea visible.
- 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
- 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.
- Retros que se convierten en terapia. Desahogarse es saludable, pero sin prompts basados en datos, el equipo no puede convertir sentimientos en experimentos.
- 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.
- 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.
- 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
- Abrir Visual Studio Code en el repositorio
team-ops. GitHub Copilot Chat carga el.github/instructions/scrum.instructions.mdcon alcance. - 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. - 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
- 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. - 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. - 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
- 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. - Actualizar el log de impedimentos. Cualquier impedimento mayor a siete días se escala al Engineering Manager mediante un mensaje de Teams.
- 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 throughputpost-commit: regenerar el JSON del burn-down siempre que cambie el alcance del sprintpre-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:
- Un compromiso propuesto de 34 a 42 puntos de historia con una nota de confianza.
- Un slice de backlog priorizado desde Azure Boards, con dependencias marcadas contra la vista de salud arquitectónica en Azure Monitor.
- Un borrador en
team-ops/sprints/47/plan.mdlisto para revisión del equipo. - 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:
- Un brief de retro en
team-ops/retros/46.mdcon patrones de flujo observados: cluster de rollbacks en el módulo de pagos, tests inestables en la suite de checkout, desbalance de guardias. - 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.
- Cada experimento tiene un dueño y un sprint objetivo, aplicado por el hook pre-push.
- Un work item de seguimiento en Azure Boards para cada experimento, creado automáticamente.
Anti-patrones
- 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.
- Logs de impedimentos que solo lee el Scrum Master. Los bloqueos son propiedad del equipo. Mitigación:
/impediment-scanpublica en el canal de Teams del equipo, no en una nota privada. - 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-scopese rehúsa a generar un spike sin rúbrica de decisión. - Burn-downs actualizados manualmente. Los gráficos manuales mienten. Mitigación: el JSON del burn-down se regenera mediante un hook post-commit.
- 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