Daily Scrum: como conduzir a reunião diária em 15 minutos
A Daily Scrum deveria durar 15 minutos e ajudar o time a decidir o que fazer hoje. Em muitas empresas, ela virou outra coisa: uma reunião de meia hora em que cada pessoa relata o que fez para o gestor, ninguém escuta o colega e os problemas de verdade ficam para depois. O resultado é um time que odeia a daily e um gestor que acha que ela serve para controlar.
O Guia do Scrum 2020 define a daily scrum como um evento de 15 minutos para os Developers, feito todos os dias úteis da Sprint, com um único propósito: inspecionar o progresso rumo à Meta da Sprint e adaptar o Sprint Backlog quando necessário. Tudo o que não serve a isso pode sair.
Abaixo está um roteiro prático, formatos que funcionam melhor que as antigas três perguntas e os erros que mais desviam a reunião. Para ver como a daily se encaixa nos demais eventos da Sprint, veja o artigo sobre eventos do Scrum.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que o Guia do Scrum diz sobre a Daily Scrum
As regras oficiais são poucas:
- Duração: 15 minutos, no máximo.
- Frequência: todos os dias úteis da Sprint.
- Horário e local: os mesmos todos os dias, para reduzir a complexidade de organizar.
- Participantes: os Developers. Se o Product Owner ou o Scrum Master estiverem trabalhando em itens do Sprint Backlog, participam como Developers.
- Formato: livre. Os Developers escolhem a estrutura e as técnicas, desde que a conversa seja sobre a Meta da Sprint e termine com um plano para o próximo dia de trabalho.
O Guia também lembra que a daily não é o único momento em que o time ajusta o plano. Os Developers costumam conversar ao longo do dia para discutir detalhes, e a daily não substitui essas conversas: ela as organiza.
A versão de 2020 retirou as três perguntas clássicas (o que fiz ontem, o que farei hoje, há impedimentos). Elas não estão proibidas, mas deixaram de ser o formato oficial porque levavam a uma rodada de relatos individuais em que a Meta da Sprint quase nunca aparecia.
Antes da primeira daily: o que preparar
- Defina horário e local fixos. O começo do dia de trabalho costuma funcionar, mas o mais importante é ser um horário em que todos os Developers estejam disponíveis. Em times remotos, deixe o link da chamada fixo no calendário.
- Torne o Sprint Backlog visível. Um quadro com as colunas "a fazer", "fazendo" e "pronto", físico ou digital, é o centro da conversa. Sem ele, a daily vira memória de cada um.
- Escreva a Meta da Sprint no topo do quadro. Ela é a pergunta permanente da reunião.
- Combine o formato. O time escolhe um dos formatos abaixo e revisa a escolha na retrospectiva, se não estiver funcionando.
Como conduzir a daily scrum: roteiro de 15 minutos
O roteiro abaixo é um exemplo que funciona para times de até nove Developers. Ajuste os tempos ao tamanho do seu time.
| Minuto | O que acontece |
|---|---|
| 0 a 1 | Alguém lê a Meta da Sprint em voz alta e lembra quantos dias faltam |
| 1 a 10 | O time percorre o quadro (ou faz a rodada, conforme o formato escolhido) |
| 10 a 13 | Impedimentos: cada um ganha um responsável por resolver ou escalar |
| 13 a 15 | Pergunta final: "estamos no caminho para cumprir a meta?" e ajuste do plano |
Três formatos que funcionam
Percorrer o quadro da direita para a esquerda. O time começa pelos itens mais perto de "pronto" e pergunta o que falta para terminá-los. Depois passa aos itens em andamento e só então aos que ainda não começaram. Esse formato prioriza terminar trabalho em vez de começar trabalho novo, e coloca os itens no centro, não as pessoas.
Foco na meta. Cada pessoa responde a uma pergunta só: "o que vou fazer hoje que aproxima o time da Meta da Sprint, e o que me impede?". É uma versão enxuta das três perguntas, com o objetivo da Sprint como filtro.
Rodada por item crítico. Quando a Sprint está em risco, o time olha só para os dois ou três itens que decidem se a meta será cumprida e reorganiza quem ajuda em cada um.
Como tratar impedimentos sem estourar o tempo
A regra que mais salva a daily é simples: a daily identifica o problema, mas não o resolve. Quando surgir uma discussão técnica, alguém diz "vamos tratar logo depois" e anota quem precisa ficar. Essas conversas de desdobramento acontecem imediatamente após a daily, só com as pessoas envolvidas.
Para cada impedimento, registre três coisas no próprio quadro: o que está bloqueado, quem vai agir e até quando. Impedimentos que dependem de outras áreas da empresa costumam ficar com o Scrum Master, que tem entre as responsabilidades provocar a remoção desses bloqueios.
Exemplo ilustrativo de uma daily bem conduzida
Um time de cinco Developers trabalha na implantação de um módulo de compras num sistema de gestão. A Meta da Sprint é "o comprador consegue emitir uma ordem de compra aprovada pelo gestor".
- Um Developer lê a meta e lembra que faltam quatro dias.
- O time olha a coluna "em teste": a tela de aprovação está quase pronta, mas falta o teste com perfil de gestor. Uma desenvolvedora se oferece para ajudar o colega dos testes logo após a reunião.
- Na coluna "fazendo", a integração com o cadastro de fornecedores está parada há dois dias porque a equipe de infraestrutura não liberou o acesso ao banco. O Scrum Master assume falar com o coordenador da infraestrutura ainda pela manhã.
- Pergunta final: a meta continua viável? O time conclui que sim, desde que o acesso saia até o dia seguinte. Se não sair, a integração será simulada e o Product Owner será avisado para renegociar o escopo.
A reunião levou 12 minutos. Ninguém relatou o que fez ontem, e ainda assim todos sabem o que acontece hoje.
Daily scrum com time remoto ou híbrido
Em times distribuídos, os maiores problemas são o atraso para entrar na chamada e a dificuldade de enxergar o quadro. Algumas práticas ajudam:
- compartilhe o quadro digital na tela durante toda a reunião;
- comece no horário, mesmo que falte alguém, para criar o hábito;
- peça câmeras ligadas só se o time combinar, mas mantenha o microfone de quem fala aberto e o resto mudo;
- em times com parte presencial, faça todos entrarem pela chamada, para ninguém ficar em segundo plano.
O artigo sobre rituais ágeis em equipes híbridas traz mais práticas para esse cenário. Se o seu time trabalha com fluxo contínuo em vez de Sprints, a reunião diária do Kanban tem outra lógica, explicada no artigo sobre Kanban meeting.
Erros que transformam a daily em reunião de status
- Relatar para o gestor. Se as pessoas falam olhando para uma única pessoa, a daily virou prestação de contas. O Scrum Master pode sair do campo de visão ou pedir que as falas se dirijam ao time.
- Resolver problemas ali mesmo. É a principal causa de daily com 40 minutos.
- Pular a daily quando "não há nada de novo". Justamente quando nada mudou é que o time precisa perguntar se a meta ainda é viável.
- Scrum Master como dono da reunião. Se ele falta e a daily não acontece, o time ainda não assumiu o evento.
- Ignorar a Meta da Sprint. Uma daily que nunca menciona a meta é só uma lista de tarefas falada em voz alta.
Esses e outros desvios aparecem com mais detalhes, e com o jeito de corrigir cada um, no artigo sobre erros comuns no Scrum. O guia completo de métodos ágeis e Scrum mostra onde a daily entra no ciclo ágil como um todo.
O que fazer a partir de amanhã
Na próxima daily, faça só duas mudanças: comece lendo a Meta da Sprint e termine perguntando se ela continua viável. Cronometre a reunião por uma semana e leve o resultado para a retrospectiva. As conversas de desdobramento que envolvem outras áreas e geram ações com prazo merecem registro: a ata de reunião com controle de ações da Projeto Diário organiza decisões, responsáveis e prazos e mostra o que atrasou, sem transformar a daily numa reunião formal.
