PI Planning no SAFe: como funciona o planejamento do trem
Doze times, mais de cem pessoas, um sistema só. O time de pagamentos precisa de uma API que o time de cadastro ainda não priorizou, a área de segurança vai exigir uma revisão que ninguém colocou no plano e a diretoria quer saber o que estará pronto no fim do trimestre. O PI Planning é o evento do SAFe que coloca todas essas pessoas, ao mesmo tempo, diante do mesmo problema: decidir o que o trem vai entregar nas próximas semanas e o que cada time precisa dos outros para conseguir.
O site oficial do SAFe descreve o PI Planning como um evento de cadência em que todo o Agile Release Train (ART) se alinha a uma missão e uma visão comuns, planeja o trabalho de maior valor e assume objetivos. Ele normalmente dura dois dias, acontece a cada 8 a 12 semanas e é liderado pelo Release Train Engineer.
Na teoria, parece uma reunião grande. Na prática, é um exercício de negociação entre capacidade e demanda, com dependências e riscos expostos na parede. Abaixo estão a preparação, a agenda dos dois dias, os resultados esperados e os erros que esvaziam o evento.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é PI Planning e onde ele entra no SAFe
PI é a sigla de Planning Interval, o ciclo de trabalho do Agile Release Train. Até a versão 5 do SAFe, a mesma sigla significava Program Increment, por isso você ainda encontra "program increment planning" em livros e vagas. O site oficial define o PI como um intervalo de 8 a 12 semanas, com preferência pelos mais curtos, formado por quatro ou cinco iterações de desenvolvimento e uma iteração final de Inovação e Planejamento (IP).
O PI Planning acontece justamente na iteração IP, para que o planejamento não roube tempo das entregas. Ele é o primeiro evento do novo PI e o que dá o ritmo a todos os outros: as iterações dos times, as demonstrações do sistema e o Inspect and Adapt, que fecha o ciclo.
Se você ainda não conhece a estrutura do framework (times, trens e portfólio), comece pelo artigo o que é SAFe. Aqui o foco é o evento.
PI Planning, Sprint Planning e Scrum
O PI Planning não substitui a Sprint Planning dos times. Ele trabalha num nível acima:
| Aspecto | Sprint Planning (Scrum) | PI Planning (SAFe) |
|---|---|---|
| Quem planeja | Um Scrum Team | Todos os times do ART, com o negócio presente |
| Horizonte | Uma Sprint (até um mês) | Um PI (8 a 12 semanas) |
| Foco | Meta da Sprint e itens do backlog | Objetivos do PI, dependências entre times e riscos |
| Duração | Até 8 horas para Sprint de um mês | Em geral dois dias |
| Saída principal | Sprint Backlog | Objetivos do PI comprometidos e quadro de planejamento do ART |
Os times continuam fazendo o planejamento de cada iteração durante o PI. O plano feito no PI Planning é uma previsão com compromissos de alto nível, não uma lista de tarefas fechada para 12 semanas.
Quem participa do PI Planning
A regra é simples: todo mundo que trabalha no trem participa, presencialmente ou conectado ao mesmo tempo. Os papéis com função definida no evento são:
- Release Train Engineer (RTE): prepara e facilita o evento, controla o tempo e conduz a resolução de impedimentos. O papel é detalhado no artigo sobre o Release Train Engineer.
- Product Management: apresenta a visão, o roadmap e as features de maior prioridade do ART Backlog.
- System Architect: apresenta a visão de arquitetura e as decisões técnicas que afetam vários times.
- Business Owners: representantes do negócio que explicam o contexto, participam das revisões e atribuem valor de negócio aos objetivos dos times.
- Times ágeis: cada time, com o Product Owner e o Scrum Master/Team Coach, estima capacidade, quebra as features em histórias, identifica dependências e escreve os seus objetivos.
Fornecedores que entregam parte da solução, áreas de segurança, infraestrutura e operações também devem estar na sala quando o trabalho delas aparece no plano. Uma dependência com alguém que não está presente vira suposição.
Como preparar o PI Planning: passo a passo
O SAFe organiza a preparação em três frentes: prontidão organizacional, prontidão de conteúdo e logística. Na prática, a preparação começa semanas antes do evento.
- Confirme o escopo do trem e a agenda. Defina datas, quem participa e qual é o horizonte do PI. Garanta que os Business Owners vão estar presentes nos momentos em que são necessários.
- Prepare o ART Backlog. Product Management ordena as features candidatas, com hipótese de benefício e critérios de aceite. Features grandes e vagas demais produzem dois dias de discussão sem plano.
- Refine com os times antes do evento. Os times precisam conhecer as features principais antes de chegar. Esse trabalho prévio é o equivalente, em escala, ao refinamento do backlog do Scrum.
- Atualize a visão de arquitetura. O System Architect leva as decisões técnicas pendentes e os itens de capacitação (enablers) que precisam entrar no PI.
- Prepare os briefings de abertura. Contexto de negócio, visão do produto e visão de arquitetura precisam caber no tempo da agenda, com mensagens claras.
- Monte a logística. Salas para cada time, um espaço central com o quadro de planejamento do ART, ferramentas digitais com acesso testado e regras de facilitação combinadas. Em formato remoto, teste tudo com antecedência.
- Calcule a capacidade de cada time. Férias, feriados, treinamentos e trabalho de sustentação reduzem o que o time consegue assumir. Planejar com capacidade cheia é a origem da maioria dos planos irreais.
A agenda do PI Planning: os dois dias
A agenda padrão divide o evento em dois dias. Os horários abaixo são ilustrativos: ajuste ao tamanho do trem e ao formato (presencial, remoto ou híbrido).
| Momento | Dia 1 | Dia 2 |
|---|---|---|
| Início da manhã | Contexto de negócio, apresentado por um executivo ou Business Owner | Ajustes de planejamento decididos na revisão da gestão |
| Manhã | Visão do produto e prioridades, por Product Management | Segunda rodada de breakouts dos times |
| Fim da manhã | Visão de arquitetura e práticas de desenvolvimento | Business Owners passam pelos times e atribuem valor de negócio |
| Início da tarde | Contexto de planejamento e regras do evento, pelo RTE | Revisão final dos planos |
| Tarde | Primeira rodada de breakouts dos times | Revisão dos riscos do trem (ROAM) |
| Fim da tarde | Revisão dos planos preliminares | Voto de confiança, retrabalho se preciso, e retrospectiva do evento |
| Depois do dia | Revisão da gestão e resolução de problemas | Fim do evento |
Dia 1: entender e rascunhar
O primeiro dia começa com alinhamento. O negócio explica para onde a empresa está indo, Product Management mostra as features prioritárias e a arquitetura apresenta as restrições técnicas. Em seguida, os times entram nos breakouts: calculam a capacidade por iteração, distribuem as histórias nas iterações, identificam dependências com outros times e rascunham os objetivos do PI.
No fim da tarde, cada time apresenta o plano preliminar, com riscos e dependências. Depois, Business Owners, Product Management, RTE e arquitetura fazem a revisão da gestão: decidem o que muda no escopo, que prioridades trocam de lugar e como resolver os conflitos de capacidade que apareceram.
Dia 2: ajustar e comprometer
O segundo dia começa com os ajustes decididos na noite anterior. Os times voltam aos breakouts, refazem o que for necessário e finalizam os objetivos. Os Business Owners passam pelos times e atribuem valor de negócio a cada objetivo.
Na revisão final, cada time apresenta o plano, os objetivos e os riscos. Os riscos do trem são tratados em grupo, e o evento termina com o voto de confiança e uma retrospectiva rápida do próprio PI Planning.
O que precisa sair do PI Planning
O site oficial lista duas saídas principais: os objetivos do PI comprometidos pelos times e o quadro de planejamento do ART (ART planning board), que mostra as datas previstas de entrega das features e as dependências entre times. Na prática, o evento também deixa os riscos do trem classificados e um voto de confiança registrado.
Objetivos do PI e valor de negócio
Os objetivos do PI resumem as metas de negócio e técnicas que times e trem pretendem alcançar. Cada objetivo é comprometido ou não comprometido. O não comprometido entra no plano e na capacidade, mas o time sinaliza que há incerteza demais para prometer. Essa separação protege a previsibilidade sem esconder ambição.
Os Business Owners atribuem valor de negócio a cada objetivo, numa escala de 1 a 10. A conversa que acompanha essa nota costuma ser mais útil do que o número: é nela que o time descobre que um objetivo que considerava secundário é o que o negócio mais espera.
Quadro de planejamento do ART
O quadro mostra as iterações nas colunas e os times nas linhas. Cada feature aparece na iteração em que deve ficar pronta, e fios (ou setas, nas ferramentas digitais) ligam as dependências. Um quadro cheio de fios cruzando na última iteração é um aviso visível de que o plano é frágil.
Riscos classificados com ROAM
Os riscos que afetam o trem são lidos em voz alta e classificados em quatro categorias:
- Resolved (resolvido): deixou de ser risco com a conversa.
- Owned (assumido): alguém se responsabiliza por acompanhar e agir.
- Accepted (aceito): o risco fica, e todos sabem que fica.
- Mitigated (mitigado): há um plano para reduzir a probabilidade ou o impacto.
Voto de confiança
Cada pessoa mostra de 1 a 5 dedos para dizer quanto confia que o trem vai cumprir os objetivos comprometidos. Votos baixos não são falha: são informação. Quando a confiança é baixa, as pessoas que votaram baixo explicam o motivo, e o plano é ajustado antes do encerramento.
PI Planning remoto ou distribuído
O SAFe prefere o evento presencial, mas considera eficaz o formato virtual ou híbrido desde que todos os membros do trem participem ao mesmo tempo. Quando o trem está espalhado por fusos horários, a orientação oficial para planejamento distribuído admite estender a agenda para mais dias, com sessões mais curtas.
Três cuidados fazem diferença no formato remoto:
- Uma sala virtual por time e um canal comum para dúvidas entre times, com alguém monitorando.
- Quadro digital único, visível para todos, em vez de um quadro por time.
- Facilitadores por sala, além do RTE, para manter o tempo e puxar dependências que ficam escondidas quando ninguém se vê.
Erros que esvaziam o PI Planning
- Backlog chegando cru. Features sem critério de aceite transformam os breakouts em sessões de descoberta. A preparação de conteúdo é o maior fator de sucesso do evento.
- Plano com capacidade cheia. Sem folga para imprevistos e para a iteração IP, o trem promete o que não consegue entregar e perde previsibilidade no segundo PI.
- Negócio ausente. Sem Business Owners na revisão da gestão, as decisões de escopo ficam para depois, e os times planejam sobre hipóteses.
- Voto de confiança de fachada. Se as pessoas sentem pressão para mostrar cinco dedos, o voto perde a função. O RTE precisa tratar o voto baixo como contribuição.
- Plano tratado como contrato. O PI Planning produz uma previsão. Mudanças durante o PI são esperadas e tratadas nos eventos do trem, não escondidas.
Como começar
Se a sua organização está avaliando o SAFe, faça antes um ensaio menor: reúna os times que dependem uns dos outros num planejamento conjunto de um trimestre, com quadro de dependências e voto de confiança. Esse exercício mostra se o problema de coordenação justifica o framework inteiro ou se práticas mais leves, como as do Scrum em escala com Nexus e LeSS, bastam. Os princípios do SAFe explicam a lógica por trás de cada parte do evento, e o guia completo de métodos ágeis e Scrum situa o SAFe entre os outros métodos.
Todo PI Planning funciona melhor quando os times dominam o básico: Sprints, backlog, estimativa e Definição de Pronto. O curso Agile Scrum Foundation da Projeto Diário cobre papéis, eventos, artefatos e práticas ágeis em vídeo, no seu ritmo, e é uma boa base para quem vai participar de um trem pela primeira vez.
