← SAFe Scrum Master: facilitação, execução e IA
07 / 8 · 60 MIN

Métricas e experiências de melhoria

Analisa trabalho aberto, composição da procura e resultados de experiências antes de comunicar uma melhoria.

Começar pela decisão

O sponsor de uma plataforma fictícia de fundos quer saber se a equipa consegue aceitar mais integrações. O relatório responde com uma média de dois dias, calculada a partir dos últimos dois pedidos concluídos. Entretanto, há dois pedidos abertos há nove e sete dias. Antes de aceitar mais trabalho, o Scrum Master ajuda a equipa a tornar essa informação visível. O objetivo não é encontrar o gráfico mais favorável. É perceber o que impede concluir e que capacidade existe para novos compromissos. No quadro do exercício, anota para cada pedido o instante de início, estado atual, instante de conclusão quando existir e motivo de bloqueio. Mantém o mesmo critério de início entre períodos. Um pedido aberto ainda não tem duração final; a sua idade continua a ser informação útil para investigar.

Resolver a amostra guiada

Usa cinco tempos de conclusão fictícios: 2, 2, 3, 3 e 20 dias. A soma é 30, a média é seis e a mediana é três. Nenhuma destas medidas permite prometer que o próximo pedido terminará em três ou seis dias. Investiga o pedido de vinte dias e as condições que o distinguem antes de o excluir. Depois compara dois períodos de 100 pedidos. No primeiro, 80 pedidos simples demoram dois dias e 20 complexos demoram dez; no segundo, as contagens invertem-se e os tempos por classe mantêm-se. As médias globais são 3,6 e 8,4 dias. O aumento reflete a composição fornecida, sem deterioração dentro das classes. A experiência global mudou e deve continuar visível. A discussão útil passa pela procura complexa, pelas restrições e pela capacidade necessária.

Propor uma experiência executável

Na equipa fictícia, muitos pedidos voltam a quem os submeteu porque falta evidência de recuperação. A hipótese é que um formulário mais claro reduza essas devoluções. Antes de o tornar obrigatório, define uma experiência em duas equipas durante duas semanas, com responsável e tempo reservado. Regista que pedidos são elegíveis, como contas uma devolução e quanto esforço consome preparar e rever o pedido. Combina um critério de paragem se o formulário dificultar respostas urgentes ou introduzir informação proibida. No final, compara resultados e recolhe exemplos de dificuldades. Se também mudou o tipo de pedidos, apresenta essa mudança. Uma descida de incidentes de seis para dois, acompanhada de uma descida de releases de vinte para quatro, não demonstra por si só benefício causal. A próxima decisão pode ser ajustar a experiência, ampliar com condições ou interromper.

Separar medidas e preservar o contexto

Num ensaio fictício, 1000 pedidos elegíveis tentam completar uma reconciliação. Cem falham antes do backend; dos 900 restantes, 891 terminam corretamente. O sucesso ponta a ponta definido no exercício é 89,1%, embora o backend isolado apresente 99%. Indica qual decisão cada medida suporta antes de a levar ao comité. Durante um incidente, o quadro também precisa de refletir o trabalho real. Se o limite é quatro e já existem quatro itens ativos, regista a exceção autorizada e discute o trabalho deslocado. Não esperes por um evento agendado para aplicar o procedimento de resposta. O laboratório local verifica apenas contas sobre dados sintéticos. Não mede uma organização, não valida causalidade nem reproduz os seis passos do workshop oficial de resolução de problemas, que continuam a exigir consulta em material autorizado.

completed_days = [2, 2, 3, 3, 20]
mean = 30 / 5  # 6
median = 3
before = (80 * 2 + 20 * 10) / 100  # 3.6
after = (20 * 2 + 80 * 10) / 100  # 8.4
end_to_end = 891 / 1000  # 0.891
NA PRÁTICA

Pedidos abertos com nove e sete dias continuam relevantes mesmo quando os dois últimos concluídos demoraram apenas dois dias.

Armadilhas comuns

Alterar o início do relógio; excluir casos difíceis sem evidência; confundir taxa de backend com resultado completo; atribuir causalidade a uma comparação curta.

Tópicos relacionados: Fluxo e capacidade · Inspect and Adapt: limites de cobertura

Leva esta ideia contigo

Uma medida só ajuda quando o seu âmbito é claro e a equipa consegue usá-la para decidir e acompanhar uma ação.

Criar conta

Referência: The Kanban Guide May 2025 · AI-Empowered SSM; official exam guide August 11 2026

SAFe® é uma marca registada de Scaled Agile, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Scaled Agile. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.