Capacidade do time: quanto cabe numa sprint?

O que é capacidade do time numa sprint

Capacidade do time é a quantidade de trabalho que o grupo consegue realisticamente entregar dentro de uma sprint, levando em conta quem estará disponível, por quantos dias, e quanto desse tempo será de fato dedicado aos itens planejados. Ela costuma ser expressa na mesma unidade que o time usa para estimar — story points, na maioria dos casos, ou simplesmente número de itens em times que preferem contar tarefas.

Capacidade não é a mesma coisa que velocity, embora as duas andem juntas. A velocity olha para trás: é a média do que o time entregou nas últimas sprints. A capacidade olha para frente: é a projeção do que o time consegue entregar na próxima sprint específica, com as férias, os feriados, os plantões e as reuniões daquela quinzena em particular. Um time com velocity média de 30 pontos pode ter capacidade de 18 numa sprint em que duas pessoas saem de férias — e planejar 30 nessa sprint é assinar um fracasso com antecedência.

Essa distinção parece detalhe, mas é onde a maioria dos planejamentos quebra. Times que planejam "pela velocity" sem ajustar pelo contexto da sprint vivem o mesmo ciclo: sprint gorda, correria na última semana, itens devolvidos ao backlog e a sensação amarga de que "a gente nunca entrega o que promete". O problema raramente é o time — é a conta que ninguém fez.

A conta da capacidade real: velocity menos a vida real

A fórmula é simples e cabe num guardanapo:

Capacidade da sprint = velocity média − ausências − interrupções previsíveis − reuniões e cerimônias

Vamos por partes.

1. Comece pela velocity média (não pela melhor sprint)

Some os pontos entregues nas últimas 3 a 5 sprints e tire a média. Use apenas itens concluídos de verdade — aquele item 90% pronto não conta, porque 90% pronto entrega 0% de valor. Resista à tentação de usar a melhor sprint da história do time como referência: aquela sprint provavelmente teve condições excepcionais que não vão se repetir. A média é chata e é exatamente por isso que funciona.

Se o time é novo e não tem histórico, aceite que as duas ou três primeiras sprints são calibragem: planeje pouco, meça, ajuste. Chutar alto no escuro só produz frustração.

2. Desconte férias e feriados

Aqui a conta é proporcional. Se o time tem 5 pessoas e a sprint tem 10 dias úteis, você tem 50 pessoas-dia de base. Uma pessoa de férias a sprint inteira tira 10 pessoas-dia (20% da capacidade). Um feriado no meio tira 5 pessoas-dia (mais 10%). Nesse cenário, um time com velocity média de 30 pontos deveria planejar algo em torno de 21 pontos — antes mesmo de considerar qualquer outro desconto.

Exemplo concreto: o time de marketing da Renata roda sprints de duas semanas para campanhas. Na sprint que atravessa o feriado de Corpus Christi, com a designer emendando a sexta, Renata desconta 3 pessoas-dia de um total de 40 e reduz o planejado proporcionalmente. Parece burocracia; é só honestidade aritmética.

3. Desconte suporte e interrupções previsíveis

Todo time tem um "imposto invisível": o time de engenharia atende incidentes de produção, o RH da Camila para tudo quando abre uma vaga urgente, o time comercial de operações responde dúvidas de outras áreas o dia inteiro. Esse trabalho é real, consome capacidade e não aparece no board da sprint — a menos que você o torne visível.

Duas formas de lidar: ou você mede quanto tempo o time gasta com isso (uma ou duas sprints anotando já dão um número razoável) e desconta da capacidade, ou cria um item recorrente de "suporte/plantão" com pontos reservados. O que não dá é fingir que a interrupção não existe. Se historicamente 15% do tempo do time vai para suporte, uma velocity de 30 pontos vira 25 ou 26 de capacidade útil — e está tudo bem, desde que a conta seja feita antes do compromisso, não depois do fracasso.

4. Desconte reuniões e cerimônias extras

As cerimônias regulares da sprint (planning, daily, review, retro) já estão embutidas na velocity histórica — o time entregava aqueles 30 pontos com as cerimônias acontecendo. O que precisa de desconto extra são os eventos fora do padrão: o workshop de dois dias, o treinamento obrigatório, a offsite do trimestre, a semana de planejamento anual. Se metade do time vai passar dois dias num evento, isso é capacidade que sai da sprint, e o planejamento precisa refletir.

O buffer honesto: por que planejar para 80%

Depois de toda a conta acima, ainda falta o passo que separa times maduros de times exaustos: não comprometa 100% da capacidade calculada. Uma referência prática consagrada é planejar para cerca de 80% e deixar 20% de folga deliberada.

Por quê? Porque a conta da capacidade cobre o previsível — férias, feriados, plantões conhecidos. O buffer cobre o imprevisível: o item que era um 3 e se revelou um 8 quando alguém abriu o capô, o bug crítico que apareceu na quarta-feira, a pessoa que ficou gripada, a dependência externa que atrasou. Nenhuma sprint real transcorre sem nenhum desses. Planejar a 100% é apostar que, pela primeira vez na história, nada vai dar errado.

E há um detalhe de teoria de filas que vale conhecer em versão qualitativa: sistemas operando perto de 100% de utilização ficam lentos e frágeis — qualquer variação pequena vira fila, atraso e estresse. É o mesmo motivo pelo qual uma rodovia a 100% da capacidade não flui: ela congestiona. Times funcionam igual. A folga não é preguiça; é o que permite absorver variação sem quebrar o compromisso.

A parte boa: buffer que sobra nunca é desperdício. Se a sprint correu limpa e sobrou fôlego, o time puxa o próximo item do topo do backlog priorizado. Adicionar escopo no fim de uma sprint tranquila é fácil e indolor; remover escopo no meio de uma sprint afogada é traumático, desmoraliza o planejamento e vira conversa difícil com stakeholder.

Por que times sempre superestimam (e não é má-fé)

Se a conta é tão simples, por que quase todo time planeja mais do que entrega? Três forças empurram na mesma direção:

Otimismo de planejamento. É um viés humano documentado: pessoas sistematicamente subestimam quanto tempo as tarefas levarão, mesmo conhecendo o próprio histórico de atrasos. Na planning, todo item parece mais simples do que será, porque a gente imagina o caminho feliz e esquece os desvios.

Pressão social e vontade de agradar. Dizer "não cabe" numa sala com o gestor e o stakeholder olhando é desconfortável. É mais fácil dizer "vamos tentar" — e empurrar o desconforto para o fim da sprint, quando ele volta multiplicado.

Confundir disponibilidade com capacidade. "São 5 pessoas por 10 dias, 8 horas por dia" é uma conta de horas de cadeira, não de trabalho focado. Ninguém produz 8 horas líquidas em itens da sprint: existem conversas, revisões, contexto trocado, e-mails, apoio a colegas. Planejar como se cada hora do expediente virasse entrega é a superestimação mais comum de todas.

A resposta para as três forças é a mesma: ancorar a conversa em dados históricos, não em intenção. A velocity média do time não é otimista nem pessimista — ela é o que é. Quando o número está na parede, a discussão muda de "vocês conseguem?" para "o histórico diz que cabe isso; o que priorizamos?".

Sinais de que a sprint está gorda

Alguns sintomas aparecem cedo e valem atenção do gestor:

• O planejado desta sprint é bem maior que a média entregue nas últimas sprints, sem nenhuma mudança real no time. Se a velocity média é 28 e o planejado é 40, alguém está apostando em milagre.
• O burndown anda de lado na primeira semana. Sprint saudável queima pontos desde cedo; sprint gorda passa dias com a linha reta porque tudo está "em andamento" e nada conclui.
• Todo mundo está com múltiplos itens abertos ao mesmo tempo. Excesso de trabalho em paralelo é o jeito clássico de parecer ocupado sem concluir nada.
• Itens começam a "pular" para a próxima sprint toda sprint. Uma vez é imprevisto; toda sprint é padrão — e padrão de sobrecarga.
• A qualidade cai no fim. Testes atropelados, revisões superficiais, "depois a gente arruma": sinais de que o time está sacrificando o bem-feito para cumprir um volume que nunca coube.
• A daily vira lista de impedimentos e desculpas em vez de sincronização de progresso — o clima da sprint gorda é reconhecível de longe.

No TeamBOX, o termômetro da sprint cruza a meta de pontos com o tempo decorrido e o que já foi entregue, e alerta o gestor quando o ritmo descola da meta — é exatamente esse tipo de sinal precoce que permite renegociar escopo na primeira semana, quando ainda é barato, em vez de descobrir o problema na review.

Negociando escopo com dados (não com queda de braço)

A cena é conhecida: a planning terminou, e chega o pedido — "dá pra encaixar mais essa demanda? É rapidinho". Sem dados, a conversa vira disputa de vontades, e geralmente vence quem tem mais cargo. Com dados, ela vira decisão de prioridade.

O roteiro que funciona tem três movimentos:

1. Mostre a capacidade e o comprometido. "Nossa média das últimas 4 sprints é 30 pontos. Esta sprint tem um feriado e o João de férias, então planejamos 22. Já estão comprometidos 22." Nada de opinião até aqui — só aritmética.
2. Transforme o pedido em troca, não em adição. "Esse item novo é um 5. Cabe, desde que algo de tamanho parecido saia. O que você prefere tirar?" Essa pergunta devolve a decisão a quem pediu — e é impressionante quantas urgências deixam de ser urgentes quando têm custo visível.
3. Proteja o objetivo da sprint. Se a troca proposta destrói o objetivo, diga isso explicitamente: "tirando esse item, a sprint perde o sentido; melhor deixar o novo pedido para a próxima, que começa em 6 dias úteis". Sprints curtas são o melhor argumento contra o encaixe: a próxima janela está sempre perto.

Um exemplo fora da TI: o time de RH do Marcos roda sprints quinzenais de processos seletivos e onboarding. Quando a diretoria pediu um mapeamento salarial "para ontem" no meio da sprint, Marcos não disse não — abriu o board, mostrou os 20 pontos comprometidos contra a capacidade de 21 e perguntou qual vaga em aberto poderia esperar duas semanas. A diretoria escolheu; a sprint sobreviveu; ninguém virou noite. Se o escopo muda com frequência no seu contexto, vale ler o que fazer quando o escopo muda no meio da sprint — há jeitos certos e errados de absorver a mudança.

Checklist rápido antes de fechar a planning

Use esta lista nos últimos cinco minutos da sprint planning, antes de bater o martelo:

• O total planejado está igual ou abaixo da velocity média das últimas 3–5 sprints?
• Descontamos férias, feriados e ausências parciais desta sprint, proporcionalmente?
• O tempo de suporte/interrupções está visível — como desconto ou como item reservado no board?
• Há eventos fora do padrão (treinamento, offsite, auditoria) que comem dias do time?
• Estamos comprometendo por volta de 80% da capacidade calculada, com folga explícita?
• Se sobrar fôlego, já sabemos qual item do backlog entra em seguida?
• Se algo estourar, já sabemos qual item sai primeiro sem matar o objetivo da sprint?
• O time inteiro — não só o gestor — concorda que o volume é realista?

Se todas as respostas forem sim, a sprint tem chance real de terminar como começou: com um compromisso que o time acredita. E times que cumprem o que prometem, sprint após sprint, constroem a única moeda que importa na relação com stakeholders — previsibilidade. Ela vale mais do que qualquer sprint heroica.