Daily Standup — o que é, regras da reunião diária e benefícios

O que é o Daily Standup?

Daily Standup — uma reunião curta da equipa Scrum realizada à mesma hora e no mesmo local todos os dias úteis. Timebox — 15 minutos. É conhecido por diferentes nomes: Daily Scrum (no Guia Scrum), sincronização matinal, morning circle, daily. O objetivo é sincronizar a equipa, identificar bloqueadores e ajustar os planos do dia. O daily não é um relatório para o gestor, mas uma ferramenta de auto-organização da equipa. A equipa decide como estruturar a reunião, não o gestor.

A origem do termo «standup» vem da prática de se reunir literalmente de pé: os participantes juntam-se em frente ao quadro e não se sentam. Isto cria uma sensação de temporariedade — ninguém quer ficar de pé mais de 15 minutos. O standup presencial ainda é utilizado por 60% das equipas (segundo o Scrum.org 2025), enquanto as restantes mudaram para o formato remoto via Zoom, Slack Huddle ou Teams. No formato remoto, é importante manter a disciplina: câmaras ligadas, sem multitarefa, preparação antecipada das respostas.

O Guia Scrum 2025 define o Daily Scrum como um evento para os Developers (desenvolvedores). O Product Owner e o Scrum Master podem assistir mas não é obrigatório. Se o PO ou SM assistirem, não dirigem a reunião. A equipa escolhe a sua própria estrutura: as três perguntas clássicas ou um board walk. Ponto chave: o daily trata de inspecionar o progresso em direção ao Sprint Goal, não o estado de cada tarefa. Se a reunião se transformar numa enumeração de tarefas no quadro, a equipa perdeu o foco no Sprint Goal.

Três perguntas do Daily Standup

Pergunta 1: «O que fiz ontem para alcançar o Sprint Goal?» — um breve resumo das tarefas concluídas. Não «trabalhei no APP-123», mas «terminei o ecrã de login, PR enviado para revisão». A formulação «para alcançar o Sprint Goal» é intencional: liga o trabalho diário ao objetivo geral da sprint. Se um desenvolvedor não vê como a sua tarefa se relaciona com o Sprint Goal, é um sinal de que a tarefa pode não ser necessária na sprint atual. No desenvolvimento móvel, os resultados de ontem incluem não só código mas também testes, documentação e configuração de CI/CD.

Pergunta 2: «O que planeio fazer hoje para alcançar o Sprint Goal?» — o plano para o dia atual. Não mais de 2-3 itens. Um desenvolvedor pode dizer: «Hoje vou terminar a ViewModel para o ecrã de perfil, escrever testes unitários e executar uma compilação num dispositivo real». Se o plano coincide com o de «ontem», é sinal de que a tarefa é demasiado grande e precisa ser decomposta. A regra dos dois dias: se uma tarefa não for concluída em 2 dias de trabalho, deve ser dividida em subtarefas; caso contrário, ficará estagnada em In Progress durante semanas.

Pergunta 3: «Que bloqueadores estão a dificultar o meu progresso?» — a pergunta mais importante. Um bloqueador é algo que o desenvolvedor não consegue resolver sozinho: esperar por uma revisão (se o SLA de revisão foi excedido), um emulador que não funciona, uma API não terminada, necessidade de acesso ao repositório. Importante: os bloqueadores devem ser nomeados mas não resolvidos durante o daily. Após a reunião, o desenvolvedor e o Scrum Master / gestor combinam a resolução do bloqueador. Segundo o Scrum.org (2025), 70% dos bloqueadores de equipas móveis estão relacionados com: espera de revisões (30%), indisponibilidade de dispositivos de teste (20%) e dependências do backend (20%).

Como realizar um standup corretamente

Hora e local. O daily realiza-se à mesma hora todos os dias — normalmente no início do dia de trabalho (9:00-10:00). Para equipas distribuídas, escolhe-se uma hora confortável para todos os fusos horários. Duração — estritamente 15 minutos. O temporizador é obrigatório. Se a equipa não terminar a tempo, o problema não é o daily mas o processo: ou há demasiados participantes, ou estão a discutir tarefas em vez de apenas nomeá-las. A regra do ping-pong: cada participante fala por no máximo 60 segundos. Depois de responder, passa a palavra ao seguinte.

Formato Board Walk. Uma alternativa às três perguntas: a equipa alterna a mover tarefas no quadro Scrum enquanto comenta as alterações. Um desenvolvedor pega na sua tarefa do To Do, move-a para In Progress e diz: «Vou buscar o APP-123 — o ecrã de encomendas, adicionar o campo de código promocional». O Board Walk proporciona uma compreensão visual do progresso e revela tarefas «esquecidas» — aquelas que estão paradas há 3+ dias. Board Walk é preferível para equipas distribuídas com Jira/Linear — todos veem o quadro em vez de ouvir um monólogo.

Para equipas remotas: as câmaras devem estar ligadas — segundo a Microsoft Research (2025), ter a câmara ligada aumenta o envolvimento em 40%. Usem um ecrã partilhado com o quadro de tarefas (Jira, Linear, Miro). Escrevam os bloqueadores no chat — isto cria um registo escrito. Incentivem os emojis de reação (exceto por instrução do utilizador — os emojis não são usados) — um polegar para cima na mensagem de um colega. Após o daily, tirem 2-3 minutos para o parking lot: os tópicos que requerem discussão separada são anotados numa lista de reuniões de seguimento. Competência chave do Scrum Master: parar a discussão durante o daily e movê-la para o parking lot.

Erros típicos nas reuniões

Erro 1: relatório de estado para o gestor. Os desenvolvedores revezam-se a ler o que está escrito no Jira, o gestor faz perguntas de esclarecimento e a reunião dura 45 minutos. Solução: lembrar que o daily é para a equipa, não para o gestor. O gestor pode consultar o estado no quadro. Se o gestor fizer perguntas, mova-as para reuniões 1:1. Uma equipa que transforma o daily num relatório de estado perde 2-3 horas por semana entre todos os participantes. Com 8 desenvolvedores, são 16-24 horas-pessoa por mês — a perda de uma sprint completa num ano.

Erro 2: resolver problemas no momento. Um desenvolvedor diz «Tenho um erro com gRPC — o projeto não compila» e toda a equipa passa 20 minutos a discutir soluções. Solução: registar o bloqueador no parking lot e continuar o daily. Após a reunião, juntar as pessoas relevantes (o desenvolvedor + quem puder ajudar) para uma discussão de 10 minutos. Segundo a Basecamp (Shape Up), apenas 20% dos problemas descobertos nos daily requerem discussão de toda a equipa. O resto é resolvido por um par de desenvolvedores em 10 minutos.

Erro 3: atrasos e ausências. Alguém chega 5 minutos após o início e é preciso repetir tudo. Solução: estabelecer a regra de que «o daily começa pontualmente, os atrasados não entram» ou «o atrasado paga uma multa» (café para a equipa). Ainda mais rigoroso: o daily realiza-se a uma hora fixa; se alguém se atrasa sistematicamente, é um problema de disciplina resolvido em 1:1. O daily é a sincronização do dia. Se um desenvolvedor o perder, não está sincronizado e corre o risco de fazer o trabalho errado para a equipa.

Erro 4: demasiados participantes. Uma equipa de 15+ pessoas, cada uma a falar um minuto — 20+ minutos no total. Solução: dividir a equipa em subgrupos por funcionalidade/módulo. Cada subgrupo realiza o seu próprio daily (5-7 pessoas). Um representante de cada subgrupo pode assistir a um standup inter-equipas (se for necessária sincronização entre equipas). Alternativa: um standup assíncrono via Slack/GeekBot onde cada um escreve o que fez / planeia / bloqueadores.

Standup assíncrono: alternativas

Standup assíncrono — um formato onde os participantes escrevem as suas respostas num chat (Slack, Telegram, Teams) ou através de um bot especializado (GeekBot, Standuply, Status Hero) em vez de uma reunião oral. Adequado para equipas distribuídas com uma diferença horária de 3+ horas. Cada participante responde às mesmas três perguntas até uma determinada hora (por exemplo, até às 11:00). O bot recolhe as respostas e publica um resumo no canal comum. Vantagens: flexibilidade, registo escrito, sem problemas de atrasos.

Desvantagens do formato assíncrono: não há interação ao vivo — perdem-se os sinais não-verbais, é mais difícil identificar bloqueadores (um desenvolvedor pode não escrever sobre um problema). Um bloqueador escrito num chat pode passar despercebido até ao final do dia. Segundo a GitLab (2025), 40% das equipas que mudaram para o standup assíncrono voltaram ao oral em 3 meses. Recomendação: usem um híbrido — 3 dias de standup oral (seg, qua, sex) e 2 dias assíncrono (ter, qui). Ou: standup oral 1-2 vezes por semana, assíncrono nos restantes dias.

Ferramentas para standup assíncrono: GeekBot (Slack) — faz as três perguntas e publica um resumo; Standuply — integra-se com o Jira e fornece acompanhamento automático; Status Hero — recolhe estados e gera relatórios semanais para a gestão. A escolha da ferramenta depende da cultura da equipa: em startups, um bot do Slack é suficiente; em ambientes empresariais, pode ser necessário o Standuply com integração em processos corporativos. Regra importante: independentemente do formato, as respostas devem ser visíveis para toda a equipa, não apenas para o gestor. A transparência é um valor central do Agile.

Particularidades do daily para equipas móveis

Uma equipa móvel enfrenta bloqueadores específicos durante o daily. Principais: compilação do projeto em CI (a compilação Gradle pode demorar 20+ minutos — se falhar, o desenvolvedor perde uma hora a depurar), espera pelo TestFlight / Firebase App Distribution (publicar uma compilação para os testers demora 30-60 minutos), problemas com emuladores e simuladores (Android Emulator requer KVM/HAXM, iOS Simulator apenas em Mac). O daily de uma equipa móvel deve incluir uma verificação rápida do estado da compilação: «A compilação passa? Todos os testes estão verdes?».

Para projetos multiplataforma (Flutter, React Native), o daily pode incluir uma pergunta sobre o estado do código partilhado. Se dois desenvolvedores estiverem a editar o mesmo ficheiro Dart simultaneamente e um fundir alterações, o segundo enfrentará conflitos. Conselho: usem Board Walk com um quadro segmentado por plataforma (Android / iOS / Shared). Isto ajuda a visualizar quem trabalha onde e se as alterações se sobrepõem. Para projetos Flutter, usem um quadro com colunas para Platform Channel, BLoC/Cubit, UI e Tests.

Preparação para o lançamento é outro ponto específico do desenvolvimento móvel no daily. 3-5 dias antes do lançamento, adicionem a pergunta: «A compilação está pronta para publicar? Todos os metadados (ícones, capturas de ecrã, descrições) estão atualizados?». Isto evita situações em que os desenvolvedores terminam de codificar no dia do lançamento enquanto a compilação e publicação demoram mais 3-4 horas. Tracker de lançamento — um quadro separado com uma lista de verificação: atualizar versionCode/versionName, verificar ProGuard, assinar AAB, enviar para a consola de desenvolvedor, escrever notas de versão.