← Voltar ao blog

Refatoração em sprints: como justificar e estimar

refatoracao estimativas qualidade

“Por que estamos gastando tempo refatorando se não entrega valor ao usuário?” Se você já ouviu isso, sabe que refatoração precisa ser vendida, não pedida.

Refatoração como valor de negócio

Refatoração entrega valor indireto, mas mensurável:

  • Velocidade: código limpo é mais rápido de modificar
  • Confiabilidade: menos bugs em código bem estruturado
  • Manutenção: onboarding mais rápido, mudanças menos arriscadas
  • Moral: desenvolvedores são mais produtivos e felizes com código limpo

Três abordagens de refatoração

1. Refatoração contínua (Boy Scout Rule)

“Deixe o código melhor do que encontrou.” Pequenas melhorias a cada PR.

Como estimar: Já incluído na estimativa da feature. Se vai mexer em um módulo, adicione 1-2 pontos para melhorá-lo.

Quando usar: Sempre. É a abordagem mais sustentável.

2. Refatoração planejada

Melhorias maiores que precisam de foco dedicado.

Como estimar: Planning Poker normal, como qualquer outra tarefa.

Exemplos:

  • “Extrair serviço de autenticação do monolito” — 8 pontos
  • “Mudar de REST para GraphQL no módulo X” — 13 pontos

Quando usar: Para mudanças arquiteturais ou código com dívida crítica.

3. Sprint de hardening

Sprint dedicado a qualidade técnica.

Como estimar: Lista de melhorias, cada uma estimada, preenchendo o sprint.

Quando usar: Raramente — apenas quando a dívida técnica acumulou a ponto de travar entregas.

Como justificar para stakeholders

Com números

“Esse módulo causa 40% dos bugs. Refatorar vai reduzir bugs em ~60%, economizando ~8 horas/semana em debugging.”

Com analogias

“É como trocar o motor do carro enquanto ele anda. Funciona, mas é arriscado e lento. Se pararmos 1 sprint para trocar direito, o carro volta a correr.”

Com risco

“Se não refatorarmos agora, cada nova feature nesse módulo vai levar 40% mais tempo. Em 3 sprints, o custo adicional já supera o da refatoração.”

Estimando refatoração

Refatoração é estimada com Planning Poker como qualquer tarefa técnica. Inclua na estimativa:

  • Análise do código atual
  • Escrita do código refatorado
  • Testes (garantir que comportamento não muda)
  • Code review
  • Deploy e smoke test

Regra do 80/20 para sprints

Sprint saudável:

  • 80%: novas features e bugs
  • 20%: refatoração e melhoria técnica

Se a refatoração consome mais de 30%, há um problema sistêmico de qualidade. Se consome menos de 10%, a dívida está crescendo.

Refatoração vs reescrita

Refatoração: melhorar estrutura sem mudar comportamento. Baixo risco. Fazer continuamente.

Reescrita: construir do zero. Alto risco. Fazer apenas quando:

  • Código legado é impossível de manter
  • Tecnologia está obsoleta (ex: jQuery → React)
  • Refatoração incremental é mais cara que reescrita

Reescritas são notoriamente perigosas. Estime com 2× o tempo que acha necessário.

Conclusão

Refatoração não é luxo — é higiene. Times que refatoram continuamente entregam mais rápido e com menos bugs a longo prazo. Inclua nas estimativas de feature, reserve 20% do sprint e justifique com dados de impacto no negócio.