O que é PI Planning no SAFe e como funcionam os dois dias

PI Planning é o evento de dois dias que abre cada Planning Interval e sincroniza todos os times de um Agile Release Train. Entra o backlog do ART e a visão; sai um plano acordado, com objetivos, dependências mapeadas, riscos discutidos e o compromisso do trem.

O SAFe o trata como o evento mais importante do framework, e a descrição que melhor o resume é que ele é a batida do coração do Agile Release Train.

Uma nota de nomenclatura antes de seguir, porque ela confunde muito material em português. PI hoje significa Planning Interval, e não Program Increment. A troca veio no SAFe 6.0, em 2023, e foi deliberada: "increment" sugeria um bloco fixo de escopo, e "interval" sugere um período dedicado a planejar e corrigir rota. A sigla continua PI, o sentido mudou.

O básico do evento

• Dois dias, a cada 8 a 12 semanas, sendo dez o intervalo mais comum
• Facilitado pelo Release Train Engineer (RTE)
• Todos planejam juntos, e essa é a premissa que sustenta o resto
• Product Management assume a prioridade das Features
• Os times assumem o planejamento das histórias e as estimativas em alto nível
• Arquitetura e experiência do usuário cuidam de governança, infraestrutura e dependência

Os benefícios que o framework atribui ao evento:

• Estabelece comunicação direta entre times e interessados
• Alinha meta de negócio com execução
• Identifica dependência e promove colaboração entre times e ARTs
• Equipara demanda e capacidade, eliminando excesso de trabalho em andamento
• Acelera decisão, porque quem decide está na sala

Esse último ponto é o menos citado e talvez o mais relevante. Numa organização normal, uma dependência entre dois times descobre-se por e-mail em três dias. Com todos na mesma sala, descobre-se em três minutos.

Os objetivos, e a parte que dá previsibilidade

O que sai do evento são os objetivos do PI: o resumo, em linguagem de negócio, do que cada time pretende entregar até o fim do intervalo. Muitas vezes correspondem à própria Feature.

E aqui está o mecanismo mais inteligente do formato, o objetivo não comprometido.

Objetivo não comprometido é aquele que o time planejou mas sobre o qual não tem confiança suficiente para se comprometer. Três coisas precisam ficar claras sobre ele, porque as três são mal entendidas:

Não é trabalho extra para fazer se sobrar tempo. Ele é planejado, com a mesma seriedade dos outros.

Ele conta no cálculo de carga. A capacidade consumida por ele é considerada.

Ele fica fora do compromisso. E é exatamente isso que torna o compromisso confiável.

O efeito é contraintuitivo e vale entender: separar o que não é compromisso é o que dá valor ao que é. Um plano em que tudo é compromisso não tem compromisso nenhum, porque ninguém acredita nele. Um plano em que 70% é compromisso firme e 30% é declarado incerto é um plano em que o negócio pode confiar nos 70%.

Exemplos de objetivo que costuma entrar como não comprometido: melhorar em 30% a performance de um relatório, ou manter o sistema com atualização em tempo real. São coisas que dependem de descobrir algo pelo caminho.

Antes da prova Teste seu nível com 30 questões no formato da prova do SAFe Agilist

Os dois dias, hora por hora

Dia 1

Contexto de negócio, apresentado pelos Business Owners, que trazem a visão do portfólio. Antes de planejar, o trem precisa saber para onde a empresa está indo.

Visão do produto e Features priorizadas, por Product Management.

Visão técnica, por arquitetura e engenharia: como as implementações serão feitas e quais opções existem.

Processo de planejamento, pelo RTE, que apresenta como a dinâmica funciona e o que se espera ao fim.

Primeiro planejamento em grupos. Aqui o evento muda de natureza: os times se separam, estimam a própria capacidade por iteração, revisam os itens que precisam de mais detalhe e montam um plano. Cada plano fica visível a todos, o que é o que permite descobrir conflito.

Apresentação do esboço, com risco e impedimento identificados.

Ajustes da gerência, ao fim do dia, com base no que apareceu. É onde escopo, capacidade e prioridade são reequilibrados.

Dia 2

Início com os ajustes decididos na noite anterior.

Segundo planejamento em grupos, com refinamento final, tratamento de impedimento e o plano definitivo.

Atribuição de valor de negócio. Os Business Owners circulam entre os times e dão nota de 1 a 10 para cada objetivo. O propósito não é ranquear times: é que, ao fim do intervalo, seja possível comparar o valor planejado com o valor realizado, e perceber quando a percepção de valor mudou no meio do caminho.

Apresentação do plano final, de cada time para todos.

Riscos do programa, discutidos abertamente entre os times. O SAFe usa quatro destinos para cada risco, e a sigla em inglês é ROAM: resolved, resolvido; owned, alguém assumiu; accepted, aceito como é; mitigated, com plano de mitigação. O valor está em nenhum risco sair da sala sem destino.

Voto de confiança. Os times declaram, coletivamente, que farão o possível para atingir os objetivos. Não é garantia de entrega: é compromisso com o esforço, e com escalar rápido se algo sair do controle, para que o atraso não seja descoberto no fim.

Se a confiança não vem, o planejamento é reformulado ali e o evento continua até o compromisso existir de fato.

Retrospectiva, próximos passos e instruções finais.

O próprio SAFe reconhece que as primeiras edições parecem caóticas. Isso é honesto e vale saber de antemão: não é sinal de que a adoção falhou.

Quem responde pelo quê durante o planejamento

Product Owner tem autoridade de conteúdo e decide sobre as histórias.

Scrum Master cuida do tempo, das dependências e das ambiguidades do próprio time.

O time define as histórias, planeja e resolve interdependência com os outros times.

E vale registrar um mecanismo que opera depois do evento, ao longo do intervalo: o Scrum of Scrums. É a reunião conduzida pelo RTE com os Scrum Masters, para acompanhar quatro coisas: se a capacidade da iteração está definida, se as histórias foram entendidas e estimadas, se apareceu dependência nova entre times, e qual impedimento está atrapalhando.

O PI Planning combina; o Scrum of Scrums é o que mantém o combinado de pé quando a realidade muda no meio.

O que decide se funciona

Na minha visão, o PI Planning é o evento do SAFe que mais depende de condição organizacional e menos de técnica.

Ele pressupõe que quem decide esteja na sala, por dois dias, sem sair para outra reunião. Pressupõe que a gerência aceite ajustar escopo à capacidade, em vez de ajustar a capacidade no papel. E pressupõe que um objetivo possa ser declarado não comprometido sem que isso seja lido como falta de comprometimento do time.

Falhando qualquer uma das três, o evento continua acontecendo e vira teatro caro: dois dias de 100 pessoas para produzir um plano que a gerência já tinha.

Na sua organização, quando um time diz na frente de todos que não tem confiança em um objetivo, o que acontece: o plano é ajustado ou o time é cobrado?