Simyl
simylflow
Início do Curso
Módulo 2: Nível de Equipe
Lição 3 de 3
17 min

Backlog e Histórias da Equipe

Como o trabalho flui de funcionalidades para histórias, e como as equipes gerenciam seus backlogs dentro do contexto da ART.

1De Funcionalidades para Histórias

No SAFe, o trabalho flui através de uma hierarquia:

ÉpicoFuncionalidadeHistória

  • Épicos são grandes iniciativas que abrangem múltiplos PIs. Eles vivem no Kanban de Portfólio e requerem Casos de Negócio Lean.
  • Funcionalidades são incrementos de funcionalidade que entregam valor ao usuário. Elas vivem no Backlog do Programa e são dimensionadas para caber dentro de um único PI. O Gerenciamento de Produto é responsável pela prioridade das funcionalidades.
  • Histórias são pequenas peças de trabalho implementáveis que uma equipe pode completar dentro de uma iteração. Elas vivem no Backlog da Equipe. O Product Owner é responsável pela prioridade das histórias.

O fluxo de decomposição: o Gerenciamento de Produto divide épicos em funcionalidades durante o Planejamento de PI. Os Product Owners dividem funcionalidades em histórias durante o planejamento de iteração (e sessões de refinamento).

Boas histórias seguem os critérios INVEST:

  • Independente — Pode ser desenvolvida sem depender de outras histórias
  • Negociável — Detalhes são discutidos, não ditados
  • Valiosa — Entrega valor claro ao usuário ou sistema
  • Estimável — A equipe pode estimar o esforço
  • Small (Pequena) — Cabe dentro de uma única iteração
  • Testável — Critérios de aceitação claros

2Habilitadores

Nem todo trabalho entrega valor direto ao usuário. Habilitadores são histórias (ou funcionalidades, ou épicos) que constroem a base técnica para capacidades futuras.

O SAFe define quatro tipos de habilitadores:

Habilitadores de arquitetura: Constroem pista de arquitetura—serviços compartilhados, APIs, infraestrutura que funcionalidades futuras precisarão. Exemplo: configurar um sistema de fila de mensagens antes de construir funcionalidades orientadas a eventos.

Habilitadores de infraestrutura: Configuram infraestrutura de desenvolvimento, teste e implantação. Exemplo: criar um pipeline de CI/CD, configurar monitoramento, provisionar ambientes.

Habilitadores de exploração: Investigam opções e reduzem incerteza. Exemplo: prototipar duas abordagens diferentes para ver qual tem melhor desempenho, histórias de spike.

Habilitadores de conformidade: Satisfazem requisitos regulatórios ou de política. Exemplo: implementar registro de auditoria, criptografia de dados ou padrões de acessibilidade.

Gerenciando habilitadores no backlog:

Habilitadores competem por capacidade com histórias de funcionalidades. Uma equipe saudável gasta aproximadamente:

  • 70-80% em histórias de funcionalidades (entrega de valor direto)
  • 20-30% em habilitadores (pista de arquitetura, débito técnico, infraestrutura)

Essa proporção não é rígida—depende da maturidade do sistema. Produtos novos precisam de mais trabalho de habilitadores; produtos maduros podem se inclinar para funcionalidades. A chave é tornar o trabalho de habilitadores visível em vez de escondê-lo.

Torne os Habilitadores Visíveis

Nunca esconda trabalho de habilitadores dentro de histórias de funcionalidades. Quando o investimento técnico é invisível, é a primeira coisa cortada sob pressão. Histórias de habilitadores separadas forçam conversas explícitas sobre o equilíbrio entre agora e depois.

3Planejamento de Capacidade e Compromisso

Durante o planejamento de iteração, as equipes determinam quanto trabalho podem se comprometer a fazer:

Capacidade = membros da equipe disponíveis × horas por dia × dias na iteração, menos reuniões e interrupções conhecidas. As equipes aprendem sua capacidade real através da experiência—é uma medida empírica, não um cálculo.

Story points estimam complexidade relativa. As equipes calibram ao longo do tempo. A métrica chave é velocidade—a média de story points completados por iteração. A velocidade se estabiliza após 3-4 iterações e se torna uma ferramenta de planejamento confiável.

Compromisso no contexto SAFe:

Os compromissos da equipe em uma iteração se alinham com Objetivos de PI estabelecidos durante o Planejamento de PI. O objetivo da iteração deve mapear para progresso em um ou mais objetivos de PI. Isso cria alinhamento rastreável do trabalho da equipe ao valor do programa.

Quando as equipes descobrem no meio da iteração que não podem cumprir um compromisso:

  1. Comunique imediatamente (transparência)
  2. Trabalhe com o PO para ajustar o escopo (negociação)
  3. Escale para o RTE se afetar outras equipes (coordenação)
  4. Nunca sacrifique qualidade para cumprir um prazo (qualidade integrada)

A medida de previsibilidade: O SAFe rastreia quão bem as equipes entregam seus objetivos de PI. Isso não é sobre punir falhas—é sobre melhorar a precisão de estimativa e planejamento ao longo do tempo. Uma equipe que entrega confiavelmente 80% dos objetivos é mais valiosa do que uma que promete 100% e entrega de forma imprevisível.

Principais Conclusões
  • O trabalho flui de Épicos → Funcionalidades → Histórias, com cada nível sendo responsabilidade de diferentes papéis
  • Habilitadores (arquitetura, infraestrutura, exploração, conformidade) constroem pista técnica
  • Equipes saudáveis alocam 20-30% da capacidade para trabalho de habilitadores
  • Previsibilidade importa mais do que compromisso excessivo heroico