O que é Sprint Planning?

O evento é definido no Scrum Guide, de Ken Schwaber e Jeff Sutherland. A edição de 2020 explicita três tópicos de discussão e vincula seu resultado ao Sprint Backlog. O Guia estabelece participantes e limite de duração, mas não prescreve uma técnica única de estimativa, quadro ou ordem rígida de perguntas.

A Sprint Planning inicia a Sprint e estabelece o trabalho que será realizado nela. O Scrum Guide de 2020 organiza a conversa em três tópicos: por que esta Sprint é valiosa, o que pode ser feito e como o trabalho escolhido será realizado. O resultado é o Sprint Backlog, formado pelo Sprint Goal, itens selecionados e um plano de entrega. Não é apenas uma reunião para preencher capacidade ou distribuir tarefas.

Por que esta Sprint é valiosa? O Product Owner propõe como o produto pode aumentar valor e utilidade. O Scrum Team colabora para definir um Sprint Goal que expresse uma direção coerente e seja comunicado a stakeholders. O objetivo pode ser refinado enquanto se escolhem itens. Evite uma frase genérica como “entregar tudo planejado”: ela não ajuda a decidir o que fazer quando surge um imprevisto. Um bom objetivo permite reconhecer se o Incremento contribuiu para o resultado pretendido.

O que pode ser feito? Os Developers conversam com o Product Owner para selecionar itens do Product Backlog. O conhecimento sobre desempenho anterior, capacidade próxima e Definition of Done pode apoiar a previsão. A seleção é responsabilidade dos Developers, não uma lista imposta por outra função. Um Product Backlog refinado ajuda a conversa, mas itens não precisam chegar como contratos detalhados. Dúvidas relevantes devem ser esclarecidas antes de assumir trabalho que ninguém entende.

Como entregar? Para cada item escolhido, os Developers planejam o necessário para criar um Incremento conforme a Definition of Done. Muitas equipes decompõem itens em trabalho de cerca de um dia ou menos, como orientação do Guia, mas o formato concreto depende do contexto. O planejamento não precisa antecipar cada tarefa do ciclo: novos detalhes surgem durante a Sprint. O importante é que o grupo tenha um caminho plausível para começar, reconheça riscos e consiga inspecionar progresso.

Quem participa? O Scrum Team inteiro participa da Sprint Planning: Product Owner, Scrum Master e Developers. Outras pessoas podem ser convidadas pelos Developers para dar aconselhamento. O Scrum Master garante que o evento ocorra, seja produtivo e permaneça dentro do timebox, ajudando o grupo a entender seu propósito. Participação não se reduz a estar na chamada: decisões sobre valor, viabilidade e trabalho precisam de diálogo real.

Quanto tempo dura? Para uma Sprint de um mês, o timebox máximo é oito horas. Sprints menores geralmente têm Planning mais curta. O limite é máximo, não meta de ocupação. Preparação contínua do Product Backlog evita usar todo o evento para descobrir o que cada item significa. Encerrar cedo é adequado quando objetivo, seleção e plano estão claros o suficiente; arrastar uma reunião para preencher agenda não aumenta previsibilidade.

Capacidade não é compromisso mecânico. Férias, apoio a operação, disponibilidade de especialistas, defeitos e dependências externas afetam quanto trabalho pode ser selecionado. Velocidade histórica ou pontos podem oferecer uma pista, mas não substituem julgamento dos Developers. Não preencha toda capacidade nominal como se não houvesse imprevistos. Se uma dependência decisiva não foi resolvida, explicite a hipótese e uma alternativa, em vez de transformar incerteza em estimativa falsa.

Objetivo e escopo têm papéis diferentes. O Sprint Goal fornece foco e alguma flexibilidade. Durante a Sprint, escopo pode ser esclarecido e renegociado com o Product Owner conforme se aprende, sem comprometer o objetivo. Isso não autoriza trocar o objetivo a cada nova demanda. Se o objetivo se torna obsoleto, apenas o Product Owner pode cancelar a Sprint. O grupo deve compreender essa diferença já na Planning, para lidar melhor com descoberta e mudança.

Faça da Planning uma conversa de produto. Pergunte quem se beneficiará, que mudança se espera e como o Incremento será examinado. Itens tecnicamente independentes podem não formar um objetivo significativo; nesse caso, discuta a direção em vez de inventar uma frase de última hora. Também é útil deixar claro o que não será buscado na Sprint, pois escolhas explícitas ajudam a proteger foco. A reunião deve produzir compreensão compartilhada, não apenas um quadro cheio.

Aprenda com o ciclo anterior. Feedback da Sprint Review pode alterar prioridades. A Retrospective pode revelar problemas de colaboração ou planejamento que devem ser considerados. Use evidências sem transformar a reunião em julgamento do passado. Se um item repetidamente não chega a Done, procure reduzir tamanho, esclarecer dependências ou mudar o plano. Repetir a mesma previsão sem investigar o fluxo não melhora a próxima Sprint.

Exemplo hipotético: uma equipe mantém um serviço de matrícula. O Product Owner apresenta reclamações de pessoas que não conseguem acompanhar o estado da inscrição. O Scrum Team formula o Sprint Goal “permitir que a pessoa veja o estado atual da matrícula sem abrir chamado”. Os Developers selecionam itens de consulta e mensagem de estado, e deixam fora uma mudança ampla no sistema de notificações que não cabe no objetivo imediato.

Na terceira parte da conversa, planejam integração com o registro acadêmico, testes de acesso e validação com suporte. Identificam uma dependência externa: a API pode devolver estados inconsistentes. Convidam uma especialista para aconselhar e registram uma alternativa de escopo. A capacidade considera duas pessoas de férias. O conjunto selecionado é uma previsão, não uma garantia de que cada tarefa imaginada terminará.

Durante a Sprint, os Developers aprendem que um dos estados não está disponível. Negociam com o Product Owner uma primeira versão que mostra os estados confiáveis e preserva o objetivo. O exemplo não prescreve tamanho de Sprint nem quantidade universal de itens; mostra como uma Planning orientada por valor permite adaptar o plano sem perder a direção.

Refinamento do Product Backlog é atividade contínua de detalhar e dividir itens para melhorar o entendimento. Sprint Planning é o evento que inicia a Sprint e cria um plano orientado pelo Sprint Goal. Refinar bem pode tornar a Planning mais produtiva, mas não decide sozinho quais itens serão selecionados nem substitui a conversa sobre valor e capacidade.

Cursos K21 recomendados