Modelo de Pauta de Sprint Planning para Equipas de Engenharia

Por que os sprints ficam sobrecarregados

O sprint planning tem uma falha estrutural que os modelos não previnem: as equipas selecionam o backlog do sprint antes de qualquer pessoa verificar a capacidade. O resultado é um sprint que parecia viável num quadro branco e colapsa na quarta-feira quando dois engenheiros estão ausentes metade da semana, um ticket triplica de âmbito e três itens tinham dependências não declaradas de um serviço que a equipa de plataforma está a reescrever.

A solução é simples e quase nunca é feita: comprometer-se com a capacidade antes de se comprometer com o trabalho. O modelo abaixo abre com uma revisão de capacidade precisamente por esse motivo.

A pauta (copiar e colar)

Duração: 2 horas para um sprint de 2 semanas; 1 hora para um sprint de 1 semana
Formato: Facilitado, com o backlog visível para toda a equipa


Secção 1 — Objetivo do sprint (10 min)

  • Uma frase: como é que um sprint bem-sucedido parece do exterior?
  • O objetivo deve ser suficientemente específico para que qualquer membro da equipa possa avaliar no final do sprint se foi atingido
  • Rejeite objetivos que são apenas uma lista de tickets ("terminar a refatoração do auth e a página de faturação") — isso é um backlog, não um objetivo

Secção 2 — Revisão de capacidade (15 min)

  • Liste cada membro da equipa pelo nome
  • Para cada um: PTO planeado, rotação de on-call, reuniões recorrentes, compromissos externos conhecidos
  • Expresse a capacidade em story points ou dias disponíveis — não em headcount
  • Este número é o teto; não selecione mais trabalho do que ele suporta

Secção 3 — Seleção do backlog (45 min)

  • Percorra os itens de maior prioridade do backlog refinado
  • Para cada candidato: a equipa tem informação suficiente para o começar, ou há questões em aberto que precisam de resposta antes do início do sprint? Questões em aberto pertencem à fila de refinamento, não ao sprint
  • Pare de selecionar quando atingir 80% da capacidade; os restantes 20% absorvem spillover e trabalho não planeado

Secção 4 — Critérios de aceitação (20 min)

  • Para cada item selecionado: declare o critério que o torna feito
  • Se a equipa não consegue declarar um critério em 60 segundos, o ticket não está suficientemente refinado — mova-o de volta para o backlog
  • Escreva-o no ticket agora, na sala; não confie em "adicionamos depois"

Secção 5 — Riscos e dependências (15 min)

  • O que poderia bloquear a entrega do objetivo do sprint fora do controlo da equipa?
  • Nomeie o responsável pela dependência; levante-o agora enquanto há tempo para o resolver antes de chegar a meio do sprint
  • Dependências não resolvidas ficam com um responsável nomeado da equipa que as vai acompanhar

Encerramento (15 min)

  • Confirme que o objetivo do sprint ainda é válido dado o trabalho selecionado
  • Atribua o secretário do recap do sprint, ou confirme a configuração do relatório automatizado
  • Confirme a data do próximo planning

O que a maioria dos modelos de sprint planning ignora

Os modelos de sprint planning mais populares focam-se no grooming do backlog e na definição de pronto. Ambos são importantes. Nenhum aborda o erro de planeamento que produz mais falhas de sprint: selecionar trabalho sem verificar a disponibilidade.

Uma equipa de cinco engenheiros a plena capacidade tem cerca de 200 story points disponíveis por sprint de 2 semanas. Uma equipa de cinco com dois engenheiros de férias, um em on-call e um num offsite de três dias tem talvez 110. Se selecionar 180 pontos no segundo sprint, já falhou. O passo de seleção é onde o sobrecompromisso acontece, e a capacidade tem de o preceder.

A segunda lacuna são os critérios de aceitação. As equipas avançam rapidamente no planning e pretendem escrever os critérios mais tarde. Mais tarde não acontece com o mesmo nível de especificidade. A pessoa que teria escrito um critério preciso na sala escreve algo mais vago de memória no dia seguinte, ou não escreve nada. Os desacordos a meio do sprint sobre o que significa "feito" são quase sempre rastreáveis a critérios de aceitação saltados no planning.

O custo acumulado destas lacunas — sprints sobrecarregados, descobertas a meio do sprint, definições relitígadas — fica evidente quando se somam: O imposto das reuniões.

Por que as notas de sprint planning são mais difíceis do que parecem

O sprint planning gera mais informação do que quase qualquer outra reunião recorrente: o objetivo do sprint, números de capacidade, a justificativa de seleção item a item, critérios de aceitação por ticket, responsáveis por dependências, itens de risco. Escrever um recap útil requer capturar tudo isso de uma forma que seja útil três dias depois quando alguém pergunta "por que cortámos esse item?"

O Pavleur gera o relatório de sprint planning automaticamente no final da chamada. Captura o objetivo do sprint, o backlog selecionado com justificativa, os critérios de aceitação conforme declarados na reunião e os responsáveis por dependências conforme nomeados. Se alguém partilhou o ecrã com o backlog ou a folha de cálculo de capacidade, esse visual está incluído no relatório juntamente com a discussão — contexto que ferramentas apenas de áudio como o Otter ou o Fireflies perderiam completamente. Quem entrou tarde ou precisa de verificar uma decisão a meio do sprint tem o registo completo. Para uma comparação de como isto difere das ferramentas apenas de áudio: Pavleur vs. alternativas.

Lidar com a mudança de plano a meio do sprint

O plano de sprint é um compromisso, não um contrato. Quando algo a meio do sprint genuinamente invalida o plano — um incidente de produção, uma dependência crítica a bloquear três tickets, uma mudança de prioridade da liderança — a resposta certa é uma chamada rápida de re-planeamento, não uma redução silenciosa de âmbito. A chamada de re-planeamento demora 20 minutos e produz um objetivo de sprint atualizado que reflete a realidade. A alternativa é um sprint que falha no papel mas se ajustou informalmente de formas que ninguém escreveu, tornando a retrospetiva mais difícil e os números de velocidade sem significado.

Construa o hábito do re-planeamento explícito. Use a mesma estrutura: capacidade atualizada, seleção revista, objetivo reafirmado. Demora muito menos tempo do que a confusão que previne.

Modelo de Pauta de Sprint Planning para Equipas de Engenharia | Pavleur