Unplanned work

Times de engenharia que perdem compromissos de sprint com frequência geralmente compartilham uma causa raiz: o trabalho não planejado consome mais capacidade do que ninguém percebe. Trabalho não planejado é qualquer tarefa que entra no fluxo do seu squad fora do processo normal de planejamento, tirando players do trabalho comprometido para lidar com bugs, incidentes, solicitações urgentes ou retrabalho. Sem ser medido, ele corrói silenciosamente a previsibilidade de entrega, leva os melhores players ao burnout e faz os compromissos de roadmap parecerem chute. Esta página cobre a definição, como medir, o que é considerado bom, como reduzir e como o DevStats expõe isso a partir das suas ferramentas existentes.

Principais conclusões

• Trabalho não planejado é qualquer trabalho que entra no fluxo de um squad sem fazer parte do plano original do sprint ou da iteração, incluindo incidentes em produção, correções urgentes de bugs, solicitações ad hoc e retrabalho causado por defeitos. Isso importa porque mesmo uma taxa modesta de trabalho não planejado pode tornar os compromissos de entrega não confiáveis e corroer a confiança dos stakeholders ao longo do tempo.
• O trabalho não planejado é medido como percentual da capacidade total: taxa de trabalho não planejado = issues não planejadas concluídas divididas pelo total de issues concluídas, multiplicado por 100. Não existe um benchmark universalmente publicado, mas a maioria dos squads de alto desempenho mantém o trabalho não planejado abaixo de 20% da capacidade total por sprint, enquanto times acima de 40% geralmente apresentam sinais de instabilidade crônica de entrega.
• O erro mais comum dos times é tratar o trabalho não planejado como um custo normal do negócio sem medi-lo. Quando não é contabilizado, os squads subestimam quanto trabalho reativo carregam, o que gera planos de sprint estruturalmente impossíveis de concluir desde o primeiro dia.
• O DevStats identifica padrões de trabalho não planejado automaticamente ao se conectar ao seu issue tracker, com dados de precisão de planejamento comparados a mais de 1.000 times de engenharia. Inicie um teste gratuito e veja os números do seu squad em menos de dois minutos.

Definição de trabalho não planejado

Trabalho não planejado é qualquer tarefa que um time de engenharia de software conclui sem que ela tenha sido incluída no plano original do sprint ou da iteração. Inclui incidentes em produção, correções emergenciais de bugs, solicitações urgentes de stakeholders e retrabalho causado por defeitos que escaparam para produção.

Tecnicamente, ele é expresso como uma taxa: taxa de trabalho não planejado = (issues não planejadas concluídas / total de issues concluídas) × 100. As fontes de dados necessárias são o seu issue tracker (Jira, Linear, GitHub Issues) e, para trabalho não planejado gerado por incidentes, a sua ferramenta de gerenciamento de incidentes. Times que usam o DevStats conseguem ver como a capacidade é alocada entre trabalho planejado e reativo diretamente do issue tracker conectado, dando aos líderes de engenharia uma visão clara de para onde o tempo comprometido realmente vai.

Altas taxas de trabalho não planejado se traduzem diretamente em consequências para o negócio: datas de lançamento perdidas, entrega de funcionalidades imprevisível e dívida técnica acumulada que torna o trabalho futuro mais lento.

Por que o trabalho não planejado importa para times de engenharia

Quando os squads não rastreiam o trabalho não planejado, os compromissos de sprint viram ficção. Um time que carrega 35% de trabalho não planejado por sprint está, na prática, planejando com apenas 65% da sua capacidade real. O sprint parece viável no papel, mas falha consistentemente na execução, e a falha é atribuída a estimativas ruins em vez da causa real.

Os efeitos vão além dos prazos perdidos. Players que passam grande parte da semana fazendo context-switching para trabalho reativo relatam menor satisfação e maior risco de burnout. A confiança dos stakeholders no time de engenharia se deteriora quando as datas do roadmap escorregam repetidamente sem uma explicação clara. O trabalho não planejado também infla o cycle time de issues de forma geral, porque o trabalho planejado em andamento é pausado ou despriorizado toda vez que um item não planejado chega.

Dentro do SPACE framework, o trabalho não planejado fica na interseção entre satisfação e desempenho: ele degrada os dois ao mesmo tempo. Medir é o primeiro passo. O que o líder de engenharia decide fazer com esses dados é onde a melhoria real acontece.

Como medir o trabalho não planejado

O cálculo é direto: divida o número de issues não planejadas concluídas em um sprint pelo total de issues concluídas e multiplique por 100 para obter um percentual. A parte mais difícil é a classificação consistente. O time precisa de uma definição compartilhada do que conta como não planejado, aplicada na criação ou triagem do ticket, não retroativamente no fechamento do sprint.

Fontes de dados para conectar: o seu issue tracker para volume e labels de tickets, a sua ferramenta de gerenciamento de incidentes (PagerDuty, OpsGenie) para incidentes em produção e os dados do seu pipeline de CI/CD para identificar hotfixes que passam por fora do processo normal de revisão. Não existe um benchmark publicado para taxa de trabalho não planejado nos relatórios DORA State of DevOps, mas profissionais do setor descrevem consistentemente os limites abaixo como sinais relevantes. Veja os benchmarks do DevStats para comparar o seu squad com times semelhantes.

Observação: esses limites variam conforme o tamanho do time, a maturidade do sistema e o modelo de release. Um time que opera um sistema de produção de alta disponibilidade vai carregar mais trabalho não planejado gerado por incidentes do que um time em desenvolvimento inicial de produto. Calibre sua linha de base antes de definir metas.

Trabalho não planejado na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que seus squads completavam consistentemente apenas 60–65% dos compromissos de sprint, mesmo com planos que pareciam razoáveis. Ela extraiu os dados do issue tracker e classificou os tickets por tipo nas oito semanas anteriores. Os dados mostraram que o trabalho não planejado representava em média 38% da capacidade total por sprint, impulsionado principalmente por bugs reportados por clientes e solicitações pontuais de dados do time de vendas. O problema não era a qualidade das estimativas. Era um vazamento estrutural de capacidade que nunca tinha sido quantificado.

Ela tomou duas decisões: criar uma rotação de suporte dedicada para que um player por squad tratasse todas as solicitações reativas sem tirar os outros do trabalho planejado, e estabelecer uma regra de que solicitações de dados de vendas precisavam passar pela triagem de produto antes de chegar à engenharia. Após dois sprints, o trabalho não planejado caiu para 22%. A taxa de conclusão de sprint subiu para 80% e o throughput do time em funcionalidades planejadas aumentou sem adicionar headcount. A medição não resolveu o problema. As decisões dela resolveram.

Como reduzir o trabalho não planejado

1. Classifique cada ticket na entrada. Adicione um campo obrigatório no seu issue tracker que distingue trabalho planejado, não planejado e de suporte. Sem classificação consistente, você não consegue medir a taxa com precisão. Revise a classificação semanalmente na retrospectiva do sprint, não apenas no final do trimestre.
2. Crie um buffer dedicado para interrupções. Reserve um percentual fixo da capacidade do sprint, tipicamente 15–20%, para trabalho não planejado. Isso não reduz o trabalho não planejado, mas torna os planos de sprint honestos. Quando o buffer enche, novos itens não planejados vão para o backlog em vez de deslocar o trabalho comprometido.
3. Rastreie o trabalho não planejado até a origem. Categorize os itens não planejados por origem: incidentes em produção, retrabalho de defeitos, solicitações de stakeholders ou incêndios de dívida técnica. A distribuição indica onde intervir. Alto volume de incidentes aponta para problemas de confiabilidade. Alto volume de retrabalho aponta para lacunas de qualidade no seu processo de code review.
4. Monitore as tendências sprint a sprint. Use os dados de sprint do DevStats para acompanhar se a taxa de trabalho não planejado está melhorando após cada intervenção. Um único sprint é ruído. Uma tendência ao longo de seis sprints é sinal.
5. Reduza a taxa de escape de defeitos upstream. Trabalho não planejado gerado por bugs em produção é um indicador defasado de problemas de qualidade mais cedo no ciclo. Aumentar a cobertura de testes e os padrões de code review reduz o volume de incidentes que gera trabalho reativo downstream.

Trabalho não planejado vs. trabalho de dívida técnica

Trabalho não planejado e trabalho de dívida técnica são ambos reativos, mas não são a mesma coisa. Trabalho não planejado é urgente e não agendado. Trabalho de dívida técnica é conhecido, agendável e frequentemente despriorizado em favor de funcionalidades.

Use a taxa de trabalho não planejado para diagnosticar problemas de previsibilidade de sprint. Use o rastreamento de dívida técnica para avaliar se o seu squad está investindo o suficiente na saúde do sistema ao longo do tempo. Alto trabalho não planejado é frequentemente um sintoma de dívida técnica adiada, então as duas métricas pertencem à mesma conversa.