Reuniões de equipa curtas e úteis têm três coisas em comum: uma agenda escrita com um tempo definido para cada ponto, um fim claro e um resultado sobre o qual alguém age. Um planeamento de sprint realista tem mais uma: a equipa compromete-se com aquilo que os sprints recentes mostram que consegue fazer, ajustado a quem está realmente disponível, e não com aquilo que espera fazer.
A maioria das equipas não começa com reuniões longas, vai lá parar aos poucos: o standup transforma-se num relatório de estado, os problemas são resolvidos na roda enquanto seis pessoas esperam e o planeamento torna-se uma negociação em que ganha a estimativa mais otimista. Este guia mostra como corrigir isto em quatro passos, usando quatro ferramentas gratuitas em kimisuite.com. Nenhuma delas exige conta.
Passo 1: Escreva a agenda antes de enviar o convite
O Meeting Agenda Generator tem seis modelos: daily standup, retrospetiva de sprint, all-hands, 1:1, chamada de descoberta comercial e arranque de projeto. Introduz um título, a duração da reunião e o facilitador, e copia ou descarrega o resultado em markdown.
O modelo de standup é assim:
- Ontem: conquistas e bloqueios (5 min)
- Hoje: prioridades (5 min)
- Bloqueios e pedidos (5 min)
- Uma coisa que ninguém sabe (uma ronda de um minuto)
O modelo de retrospetiva soma 42 minutos: preparar o contexto (5), o que correu bem (10), o que não correu (10), ações concretas, com responsável e prazo (15), e uma rápida verificação de energia de 1 a 5 (2).
Um detalhe a ter em conta: os tempos das secções são fixos em cada modelo. A duração que escreve aparece no cabeçalho, mas as secções não são reajustadas. Se a sua retro tiver 30 minutos, encurte-as manualmente antes de enviar o convite. É precisamente essa a ideia: decide antecipadamente o que fica com menos tempo.
Passo 2: Mantenha o standup nos 15 minutos
O Scrum Guide (versão de novembro de 2020, scrumguides.org) descreve o Daily Scrum como "um evento de 15 minutos para os Developers", realizado "à mesma hora e no mesmo local em todos os dias úteis do Sprint". O seu objetivo é inspecionar o progresso em direção ao Sprint Goal e adaptar o plano para o trabalho seguinte.
O mesmo guia diz também que os Developers "podem escolher a estrutura e as técnicas que quiserem". As três perguntas clássicas são um hábito, não uma regra. Se "o que fizeste ontem?" se transformou numa récita, mude a pergunta.
O Standup Question Generator ajuda nisso. Escolhe entre 1 e 10 perguntas aleatórias de um de quatro bancos: quebra-gelo, retrospetiva, profundas e divertidas. Comece o standup com uma pergunta quebra-gelo uma vez por semana ou leve à retrospetiva perguntas como "Onde perdeste mais tempo?" ou "O que precisamos de DEIXAR de fazer?".
Passo 3: Estime as histórias antes do planeamento
O planeamento é mais rápido quando as histórias já têm tamanho. O Story Point Estimator é uma versão individual do planning poker. Escolhe Fibonacci (1, 2, 3, 5, 8, 13, 21, 40, 100) ou tamanhos de T-shirt (XS a XXL, mais "?"), escreve a história, escolhe uma carta e define a sua confiança como baixa, média ou alta. As estimativas vão para uma lista contínua com o total de pontos.
A parte útil são as indicações por baixo de cada carta. Um 13 mostra "Grande · divida-a antes de se comprometer", um 21 "Demasiado grande · divida em histórias mais pequenas", e "?" significa que precisa de mais informação antes de estimar. Se der por si a escolher 13 ou mais, a história não está pronta para o sprint.
As estimativas individuais são um ponto de partida. A equipa continua a discuti-las, porque uma pessoa sozinha não sabe o que os outros sabem.
Passo 4: Preveja o sprint a partir da sua própria velocity
O Scrum Guide não menciona velocity nem story points. Diz, no entanto, que quanto mais os Developers souberem sobre "o seu desempenho passado, a sua capacidade futura e a sua Definition of Done, mais confiantes estarão nas suas previsões de Sprint". A velocity, ou seja, os pontos que uma equipa concluiu por sprint, é uma forma comum de medir isso.
A Sprint Velocity Calculator usa os seus três últimos sprints e a sua capacidade para o próximo, em percentagem, e devolve:
- A média dos três sprints
- Uma tendência: a subir se o último sprint ficou mais de 10 por cento acima do anterior, a descer se ficou mais de 10 por cento abaixo, caso contrário estável
- Uma previsão: a média multiplicada pela sua capacidade
- Quantos sprints são precisos para concluir 50 pontos com essa previsão
Um exemplo prático
Uma equipa de cinco pessoas concluiu 24, 31 e 27 pontos nos últimos três sprints. Uma pessoa estará de férias durante todo o próximo sprint, por isso a capacidade é de 80 por cento.
- Média: (24 + 31 + 27) / 3 = 27.3 pontos
- Tendência: 27 está mais de 10 por cento abaixo de 31, por isso a calculadora mostra "Tendência descendente — investigue os bloqueios"
- Previsão: 27.3 x 0.8 = 21.8 pontos
- Sprints para concluir 50 pontos: 50 / 21.8 = 2.3, arredondado para 3
Agora pegue nas histórias estimadas no passo 3: 8, 5, 5, 3 e 2 pontos, 23 no total. É mais do que a previsão de 21.8. O plano honesto é 8 + 5 + 5 + 3 = 21 pontos, ficando a história de 2 pontos como a primeira a puxar se a equipa terminar mais cedo.
A tendência compara apenas os dois últimos sprints, por isso basta um sprint difícil para indicar "a descer". Antes de o encarar como um problema, pergunte na retrospetiva o que atrapalhou. E nunca compare a velocity entre equipas: os pontos de cada equipa significam coisas diferentes.
Onde entra o KIMISUITE
As ferramentas funcionam por si só. Se quiser ter as reuniões e o quadro do sprint num só lugar, duas apps do KIMISUITE cobrem os passos acima.
O Meeting Hub gere videoconferências a que os convidados se juntam no browser através de um link. Ao agendar uma reunião, pode colar a agenda na descrição. Durante a chamada, o menu Ferramentas tem um temporizador (1, 5, 10, 15, 30 minutos ou personalizado) que todos veem e que fica vermelho aos 0:00. Uma votação com duas ou mais opções ajuda uma retro a decidir que ação tomar primeiro. Depois da reunião, a transcrição pode ser descarregada em todos os planos e, nos planos Pro e Enterprise, um resumo com IA lista as ações, com responsável e prazo, e as decisões tomadas.
O Task Hub aloja o próprio sprint. O modelo Engineering Sprint cria listas, etiquetas e cartões de exemplo para um novo quadro. A partir do plano Grow, pode adicionar campos personalizados, como um campo numérico, e definir dependências, para que um cartão mostre o que bloqueia ou o que o bloqueia. No plano Business, a AI Task pode transformar o resumo e a transcrição de uma reunião concluída no Meeting Hub em propostas de cartões, que revê antes de serem criados. Saiba mais sobre este fluxo em Task Hub: de uma nota de voz a um quadro de tarefas.
Ambas as apps estão no mesmo workspace do KIMISUITE, que é faturado por workspace e não por utilizador. Para perceber o que isso significa para uma equipa, veja preço por workspace, não por utilizador. Cada app inclui um período experimental de 14 dias.
Perguntas frequentes
E se o nosso standup continuar a passar dos 15 minutos?
Tire dele a resolução de problemas. Quando um tema precisar de mais de um minuto, identifique-o, indique as duas pessoas que precisam de falar e deixe-as reunir-se logo a seguir.
Temos de usar as três perguntas do standup?
Não. O Scrum Guide de 2020 deixa os Developers escolher a estrutura, desde que a reunião inspecione o progresso em direção ao Sprint Goal e adapte o plano. Uma pergunta diferente por semana evita que a ronda se torne um relatório.
De quantos sprints preciso para calcular a velocity?
A Sprint Velocity Calculator usa os três últimos. Com menos sprints, a média é pouco fiável; sprints muito antigos descrevem uma equipa que pode entretanto ter mudado.
Que capacidade devo indicar quando alguém está ausente durante parte do sprint?
Estime a parte dos dias úteis da equipa que está realmente disponível. Numa equipa de cinco, uma pessoa ausente durante todo o sprint corresponde a 80 por cento. Uma pessoa ausente três dias num sprint de dez dias dá 47 de 50 dias-pessoa, ou seja, cerca de 94 por cento.
