Neste capítulo, você vai aprender a construir um roadmap e um plano de release que comunicam direção sem prometer o que o empirismo não permite prometer. É a ponte entre a visão de longo prazo e a Sprint que começa na segunda-feira.

Roadmap é a representação de como o produto deve evoluir ao longo do tempo, organizado por metas ou resultados, não por lista de funcionalidades com data. Plano de release descreve o que se pretende entregar no próximo marco, com base na capacidade observada do time. Os dois são atualizados a cada Sprint com o que foi aprendido; nenhum é contrato.

Roadmap orientado a resultados

O roadmap tradicional lista funcionalidades em trimestres e vira promessa. O roadmap ágil lista metas: “reduzir o abandono no cadastro”, “permitir pagamento sem cartão”, “abrir o produto para o mercado argentino”. Cada meta tem uma métrica e uma janela aproximada de tempo. As funcionalidades que vão atingir a meta são decididas mais perto da execução, com mais informação.

• Agora
  A meta atual, com os itens já refinados no topo do backlog.
• Em seguida
  A próxima meta, com hipóteses de funcionalidades ainda abertas.
• Depois
  Direções possíveis, sem compromisso de escopo nem de data.

A cebola do planejamento

O Agile Planning Onion ajuda a situar cada decisão: no centro, o dia e a Sprint; ao redor, a release; mais fora, o produto, o portfólio e a estratégia. Quanto mais externa a camada, menos detalhe e mais horizonte. O erro comum é tratar a camada externa com o detalhe da interna, prometendo em janeiro o que será entregue em novembro.

Plano de release com base em capacidade

O plano de release responde a duas perguntas: o que entra no próximo marco e quando ele deve acontecer. A resposta vem da capacidade observada do time, não do desejo do stakeholder. Se o time conclui em média vinte pontos por Sprint e a release tem cem pontos, são cinco Sprints; o prudente é planejar seis, para absorver a variação. Fixar o escopo e deixar a data flutuar, ou fixar a data e negociar o escopo, são as duas opções honestas. Fixar os dois é a origem de boa parte das crises.

O que o Product Owner comunica

Imagine o comandante de um navio informando a rota aos passageiros. Ele diz o destino, a próxima escala e a previsão de chegada, e avisa que o mar pode mudar o plano. Não lista cada manobra. O Product Owner apresenta o roadmap assim: direção clara, próximo marco concreto, previsões com intervalo, revisão a cada Sprint Review. No curso CSPO, cada equipe constrói o roadmap e o plano de release do produto que definiu, e descobre na prática a diferença entre planejar e prometer.

O próximo capítulo entra no artefato que sustenta tudo isso: o Product Backlog.