O que realmente é um Scrum Master no dia a dia
Muita gente acha que Scrum Master é aquele que coordena reuniões e anota papeleira. Na prática, é bem mais chatinho do que isso. A pergunta scrum master o que faz parece simples, mas a resposta depende muito do time, do contexto e, honestamente, da quantidade de caos que já passou pela sua mesa. Começando pelo básico, um Scrum Master é o facilitador do processo. Ele remove impedimentos, garante que as cerimônias aconteçam e protege o time de interrupções externas. Isso na teoria. Na prática, envolve negociar com cinco gerentes que querem entregáveis diferentes no mesmo sprint, convencer um PO que mudou de ideia três vezes no meio do sprint a respeitar a lista priorizada e, ao mesmo tempo, fazer o time entender que burburinho durante a planning não ajuda ninguém.
Scrum Master o que faz: as responsabilidades práticas
As cerimônias do Scrum são óbvias, mas a forma como você as conduz faz toda diferença. Daily de 15 minutos virou uma fila de status para o chefe em muitos times que já vi. O trabalho do SM é transformar aquilo em um sincronismo real. Se alguém está travado, entra no microfone depois, não durante. Planning é onde os problemas de estimativa se acumulam. Um SM bom não deixa o time prometer o que não consegue. Se o time disse que vai entregar três stories e o negócio quer cinco, o papel do Scrum Master é mediar isso com dados, não com força de vontade. Eu vi um time que ficava sempre completando 40% do comprometido porque nunca diziam não. A virada aconteceu quando paramos de transformar planning em promessa pública e passamos a tratá-la como hipótese baseada em throughput real.
Sprint Review e Retrospectiva merecem cuidado separado. A review não é apresentação de sucesso, é feedback real dos stakeholders. Já a retrospectiva é onde a maioria dos times falha. Eu tenho um caso específico que lembro até hoje: um time fazia retrospective toda semana, mas nunca saía nada dela. As ações propostas eram sempre genéricas como "melhorar comunicação" ou "se esforçar mais". A solução que funcionou foi simples. Passei a pedir que cada ação tivesse um responsável definido e um critério de verificação. Algo como "fulano vai criar um template de definição de pronto para testes, pronto quando estiver no confluence até sexta". Sem isso, a retrospectiva vira apenas desabafo sem efeito. Um ponto que poucas pessoas entendem é o conceito de definition of done. Sem isso, você tem gente dizendo que deliverou e outras dizendo que ainda não tá pronto. Eu trabalhei num projeto ondeQA considerava como done um código sem teste automatizado porque o teste manual já estava sendo feito. O desenvolvedor achava que tinha terminado na revisão de código. A divergência causava bloqueios constantes. A resolução foi colocar no definition of done que nenhuma story era considerada done sem pipeline de CI passando, além de revisão de código e teste unitário cobrindo pelo menos 80% das linhas críticas. Simples assim.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pegadinhas que ninguém conta
Scrum Master não é gerente de projeto disfarçado. Essa confusão acontece tanto que gera frustração nos dois lados. Se você está dando seguimiento individual, cobrando prazos e cobrando metas de pessoas, você não está sendo SM, está sendo chefe. O papel do SM é servir o time, não Gerenciar o time. Outra armadilha comum é achar que o framework Scrum tem que ser seguido à risca. Eu já vi times que implementavam Scrum sem nunca ter lido o guia completo e adaptavam as cerimônias baseado no que achavam que era certo. O resultado era um processo híbrido bagunçado que não funcionava nem como Scrum nem como qualquer outra coisa. O conselho pragmático aqui é implementar o guia oficial por pelo menos três sprints antes de pensar em qualquer adaptação.
Também é importante notar que Scrum não serve para tudo. Times com alta dependência entre áreas, onde uma entrega só acontece porque outra área já terminou semanas antes, vão sofrer muito com sprints curtos. Eu vi um time de infraestrutura que precisava de ciclos de meses para fazer deploy de mudanças estruturais. Forçar sprint de duas semanas ali só gerava frustração e ceremonies vazias. Nesses casos, Kanban ou um Híbrido com Kanban faz mais sentido. Scrum tem limitações reais e admitir isso é mais profissional do que tentar encaixar o quadrado no buraco redondo. Outro ponto é a figura do Product Owner. SM e PO são papéis diferentes e precisam ficar claros desde o início. Quando alguém tenta exercer os dois, ou quando o PO não tem poder de decisão real porque precisa aprovar tudo com três gerentes, o Scrum Master fica travado. Não adianta facilitar cerimônias se o dono do produto não pode decidir. O cenário mais comum que eu vejo é o PO sendo um representante que passa a metade do tempo reunido e a outra metade esperando aprovação. Nesses casos, o SM precisa identificar isso cedo e escalar, senão o sprint inteiro vira um processo burocrático sem direção.
O trabalho de remoção de impedimentos também é subestimado. Muita gente acha que é só anotar e torcer. Num projeto que participei, o impedimento principal era uma dependência com outra equipe que não respondia nos prazos. Tivemos que institucionalizar uma cerimônia extra de alinhamento quinzenal entre os dois SMs, com um acordo formal de SLA interno. A mudança foi drástica, mas o problema não era resolvido só com "cobrar nos canais adequados". Às vezes a solução é criar um canal novo e estruturado. Se você está começando nessa função, leia o guia Scrum oficial, pratique com times pequenos primeiro e não tenha medo de dizer quando algo não está funcionando. Scrum Master eficaz não é o que faz tudo perfeito, é o que reconhece os problemas antes que eles destruam o sprint.
