Entrega de produto ágil no SAFe: do cliente ao backlog priorizado

Entrega de produto ágil é a competência do SAFe que liga o foco no negócio à execução, e o próprio framework a trata como o seu centro. Ela cobre três frentes: centralização no cliente, priorização do backlog e o pipeline de entrega contínua.

Dito de outra forma, é onde o framework decide o que construir. E o mérito dela está menos nas ferramentas e mais no efeito: quando funciona, a decisão de prioridade deixa de ser opinião de quem tem mais autoridade na sala e passa a ser um cálculo que qualquer um pode conferir.

Centralização no cliente é postura, não etapa

Empresa centrada no cliente entrega solução projetada a partir de uma compreensão profunda da necessidade dele. O retorno que o SAFe associa a isso é lucro maior, cliente satisfeito e time mais engajado.

Mas o ponto que costuma se perder é que centralização no cliente é um jeito de pensar, não uma fase do processo. Toda decisão é considerada do ponto de vista de quem usa. Não existe a semana do cliente.

Para chegar nessa postura, o SAFe recomenda um instrumento que já conhecemos: o Design Thinking. No framework, ele aparece organizado em duas etapas.

Entender o problema. Descobrir tudo sobre quem usa, o que quer e onde sofre, e depois definir o que será proposto. As ferramentas citadas são persona, que é a pessoa fictícia construída para representar quem vai usar, e mapa de empatia, que ajuda o time a construir compreensão real em vez de suposição.

Projetar a solução correta. Desenvolver o que foi definido, por mapa de jornada, protótipo, história de usuário e desenho de solução. E entregar para o cliente validar se a direção está certa.

Repare que a segunda etapa termina em validação, e não em especificação aprovada. É a mesma lógica do Lean Startup: o ciclo fecha em decisão, não em entrega.

De conhecimento a item de backlog

Aqui existe uma passagem que costuma ser tratada como formalidade e é onde muito valor se perde: transformar o que se aprendeu sobre o cliente em algo que o time consiga construir.

O SAFe usa histórias de usuário para isso. A forma de pensar que ajuda: a história é toda a documentação necessária para que aquilo possa se transformar em código utilizável. Não é o título do card.

E aparecem dois níveis, que vale distinguir com clareza porque a confusão entre eles produz backlog inútil.

Feature é o trabalho no nível do ART. Reflete requisito funcional e não funcional, e os critérios de aceitação normalmente são definidos durante o PI Planning.

História é o incremento pequeno, que se desenvolve em horas ou dias e é fácil de estimar. A regra prática: nenhuma história dura mais que uma iteração. Se dura, não é história, é feature disfarçada.

Existe ainda a história habilitadora, que cobre trabalho que não entrega funcionalidade visível mas viabiliza o que vem depois: exploração, arquitetura, infraestrutura, documentação e conformidade. Ela existir como item explícito é o que impede esse trabalho de ficar invisível, e é o que dá ao time argumento para defendê-lo na priorização.

Feita a Feature e quebradas as histórias, elas entram no ART Backlog. Uma nota de nomenclatura: até o SAFe 5 isso se chamava Program Backlog, e o SAFe 6.0 trocou "Program" por "ART" em todo o framework. Material anterior a 2023 usa o nome antigo.

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

Estimar para poder comparar

Antes de priorizar, é preciso estimar. E o objetivo da estimativa aqui não é prever prazo, é tornar itens comparáveis.

O método mais usado é o planning poker: o time discute o item e cada pessoa atribui um valor, em conjunto. O ganho não é a precisão do número. É que a discussão inclui todas as perspectivas, produz entendimento comum e cria compromisso, porque a estimativa foi feita por quem vai executar.

Estimativa feita por uma pessoa e comunicada ao time produz o número mais rápido e o compromisso mais fraco.

WSJF: priorizar por economia, não por insistência

Esta é a parte mais valiosa da competência, e a menos aplicada.

Para obter o melhor retorno, o SAFe trata o sequenciamento do trabalho como a decisão que mais importa. E para priorizar por economia Lean, são necessárias duas informações:

1. O custo do atraso: quanto se perde por não entregar aquilo agora
2. O custo de implementar, usado como duração

Se você quantificar somente uma coisa, quantifique o custo do atraso.

Donald G. Reinertsen

O método é o WSJF, de Weighted Shortest Job First. Ele divide o custo do atraso pela duração, e o efeito é direto: sobe na fila o item de maior custo de atraso e menor duração.

Vale entender por que isso é diferente do que costuma acontecer. Priorização normal ordena por valor: o item mais valioso primeiro. O WSJF ordena por valor por unidade de tempo. Um item muito valioso que leva seis meses pode ficar atrás de três itens medianos que levam duas semanas cada, porque os três entregam antes e liberam a fila.

Como ninguém sabe medir custo de atraso em reais com precisão, o SAFe usa estimativa relativa: compara os itens entre si, em vez de tentar valor absoluto. É rápido e suficiente para ordenar, que é tudo o que a priorização precisa.

Quem participa do cálculo: Business Owners, Product Management, Product Owners e System Architects. A conta completa está no material oficial do SAFe sobre WSJF.

E aqui está o efeito político do método, que na minha visão é o real motivo de ele existir: quando a fila é resultado de uma conta que todos veem, discutir prioridade passa a ser discutir os números da conta. Some a discussão sobre quem pediu primeiro.

O que essa competência entrega

Ao fim dela, existe um caminho completo: o cliente foi compreendido, a solução foi proposta e validada, o conhecimento virou Feature e história, tudo entrou no ART Backlog e a fila foi ordenada por economia.

O que falta é a terceira frente, o pipeline de entrega contínua, que é o que leva isso de fato até produção, e é assunto de um artigo próprio.

Uma observação sobre adoção, porque ela decide o resultado. As três frentes são independentes na prática, e as organizações costumam adotar a primeira e a terceira: fazem workshop de Design Thinking e investem em pipeline. A do meio, priorizar por custo de atraso, é a que exige que alguém aceite que a sua prioridade caia na fila por um cálculo. É a mais barata de implementar e a mais difícil de sustentar.

Na sua organização, a ordem do backlog é resultado de um critério que qualquer pessoa poderia recalcular, ou de uma negociação que precisa ser refeita a cada trimestre?