paulasilvatech ASP Personas do SDLC Agêntico v1.0.0
EN PT ES
09 enablement · Delivery

Scrum Master

Fluxo, retros, saúde de sprint.

Atualizado: 2026-04-24 14 seções Baixar .zip

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

  1. 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.
  2. Retros que viram terapia. Desabafar é saudável, mas sem prompts ancorados em dados, o time não converte sentimentos em experimentos.
  3. 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.
  4. Spikes que nunca acabam. Um spike iniciado para responder uma pergunta vira um projeto de pesquisa aberto. Sem decisão, sem entregável.
  5. 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ã

  1. Abra o Visual Studio Code no repositório team-ops. GitHub Copilot Chat carrega o .github/instructions/scrum.instructions.md escopado.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. Reconcilie o burn-down do sprint entre Azure Boards e GitHub Projects. Qualquer deriva é registrada como hook warning.

Revisão no fim da tarde

  1. 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.
  2. Atualize o log de impedimentos. Qualquer impedimento com mais de sete dias é escalado para o Engineering Manager via mensagem no Teams.
  3. 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

AgenteArquivoPropósito
flow-coach.github/agents/flow-coach.agent.mdFacilitar 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

ComandoArquivoPropósito
/plan-sprint.github/prompts/plan-sprint.prompt.mdGerar uma proposta de sprint plan ancorada no histórico de throughput
/run-retro.github/prompts/run-retro.prompt.mdProduzir um brief de retro com observações ancoradas em dados e experimentos candidatos
/impediment-scan.github/prompts/impediment-scan.prompt.mdDetectar PRs parados e itens envelhecidos do Azure Boards no time
/spike-scope.github/prompts/spike-scope.prompt.mdEscopar 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)ArquivoPropósito
team-ops/sprints/**.github/instructions/scrum.instructions.mdEstrutura de cerimônia, fraseado alinhado ao Scrum Guide, distinção Agile-não-agile
team-ops/retros/**.github/instructions/retros.instructions.mdFraming de retro, causa sistêmica acima de culpa individual
team-ops/spikes/**.github/instructions/spikes.instructions.mdTemplate 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 throughput
  • post-commit: regenera o JSON do burn-down sempre que o escopo do sprint muda
  • pre-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.

MCPStatusUso nesta persona
GitHub MCP ServerOficialLer boards de Projects, runs do Actions e estado de PR para reconciliação de burn-down
Azure DevOps MCP ServerOficial (Microsoft)Ler e atualizar iterações de sprint, work items e impedimentos no Azure Boards
Azure MCP ServerOficial (Microsoft)Consultar Azure Monitor para contagens de incidente que afetam o fluxo do sprint
Microsoft Learn Docs MCPOficialAncorar guia de facilitação em Microsoft Learn e GitHub Docs
Microsoft 365 Agents SDK MCPOficial (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:

  1. Um compromisso proposto de 34 a 42 story points com uma nota de confiança.
  2. Uma fatia de backlog ranqueada do Azure Boards, com dependências sinalizadas contra a view de architecture-health no Azure Monitor.
  3. Um rascunho em team-ops/sprints/47/plan.md pronto para review do time.
  4. 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:

  1. Um brief de retro em team-ops/retros/46.md com 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.
  2. 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.
  3. Cada experimento tem um dono e um sprint-alvo, aplicados pelo hook pre-push.
  4. Um work item de follow-up no Azure Boards para cada experimento, criado automaticamente.

Anti-padrões

  1. 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.
  2. Logs de impedimento que só o Scrum Master lê. Bloqueios são propriedade do time. Mitigação: /impediment-scan posta no canal do time no Teams, não em uma nota privada.
  3. Spikes que pulam a rubrica de decisão. Um spike sem critérios de saída vira pesquisa-por-pesquisa. Mitigação: /spike-scope se recusa a fazer scaffold de um spike sem rubrica de decisão.
  4. Burn-downs atualizados manualmente. Gráficos manuais mentem. Mitigação: o JSON do burn-down é regenerado por hook post-commit.
  5. 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étricaLinha base (manual)Meta (agentic)Medição
Acurácia de compromisso do sprintMais ou menos 35 por centoMais ou menos 10 por centoPontos concluídos versus comprometidos
Taxa de conclusão de experimento de retro20 por centoAcima de 70 por centoRastreador de experimentos entre sprints
Idade mediana de impedimento9 diasMenos de 3 diasAnalytics do log de impedimentos
Aderência ao time-box de spike45 por centoAcima de 90 por centoAuditoria de fechamento de spike
Tempo de prep de cerimônia por semana6 horasMenos de 2 horasLog de time-to-agenda
Eficiência de tokensN/AMenos de 150k tokens por semanaRelatório de uso do Copilot

Maturidade em quatro níveis

NívelNomeMarcadores
L1ManualBurn-down feito à mão, retros de memória, impedimentos em canal paralelo
L2AssistidoGitHub Copilot Chat para rascunho de cerimônias, sem agente, ferramentas misturadas para dados de fluxo
L3AumentadoAgente Flow Coach, quatro slash prompts, instruções escopadas, Azure Boards e GitHub Projects reconciliados
L4AutônomoKit 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