Sprint planning: dicas para reuniões mais dinâmicas e produtivas

Sprint planning: dicas para reuniões mais dinâmicas e produtivas

• 30/05/2019
• Robson Camargo

 

Sprint Planning é a reunião do Scrum, na qual é feito o planejamento de um Sprint. O propósito da Sprint Planning é alinhar o time de desenvolvimento e o Product Owner.

Se você investir algum tempo prévio refinando o Product Backlog (tarefa principal do Product Owner), com certeza, você conseguirá fazer uma Planning produtiva. Mas há outras más práticas que podem ser evitadas para conseguir um bom resultado.

Como é uma Sprint Planning?

A Sprint Planning ou Reunião de Planejamento de Sprint é uma cerimônia simples dentro do processo ágil Scrum.

Normalmente, no Sprint Planning estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

O objetivo da Sprint

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para a Sprint, que é uma breve descrição daquilo que se tentará alcançar na Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

O Scrum Sprint Planningnormalmente é divido em duas partes, sendo que, na primeira parte é apresentado o que vai ser desenvolvido e, na segunda, é definido o como vai ser feito.

Ao finalizar a Sprint Planning teremos dois artefatos prontos: Meta do Sprint e o Sprint Backlog. A revisão e validação do sucesso ou não da planning irá acontecer no Sprint Review, que é realizado ao final do Sprint.

Dicas para Sprint Planning mais dinâmicas e produtivas

Nem sempre a Sprint Planning é produtiva e isso ocorre porque é muito fácil perder o foco e a eficiência nesse encontro porque é, sem dúvida, o rito mais maçante do Scrum. Vale a pena lembrar que o Scrum é uma metodologia ágile para gestão e planejamento de projetos de software.

Por isso, é necessário fazer de maneira assertiva para não desperdiçarmos o tempo do time.

É fundamental e imprescindível que todo o time de desenvolvedores esteja disponível para participar da Sprint Planning. Ausências não eximem os ausentes da responsabilidade do que for acordado nesta reunião.

Além disso, é importante que todos os desenvolvedores sejam capazes de dizer o quanto estarão disponíveis para a próxima sprint. Jamais acredite que 100% dos membros do time estarão disponíveis 100% do tempo e não se esqueça que novos membros podem entrar no time e que demoram a se adaptar.

Em geral, assumir uma capacidade de produção de 80% do total de horas trabalhadas é uma prática aceitávelpara cobrir possíveis ausências não previstas (doença, atrasos diversos, detalhes não previstos, bugs urgentes etc).

Para que a sprint seja minimamente bem-sucedida, os desenvolvedores jamais devem superestimar sua capacidade de produzir.

Para cada tarefa a ser estimada (seja com Planning Poker ou qualquer outra técnica), cada detalhe que possa afetar a capacidade do time de entregar aquela tarefa deve ser analisado.

Ter uma definição de pronto bem definida ajuda bastante, pois dá uma noção mais clara de todas etapas que cada tarefa deverá percorrer para ser entregue de fato.

Falhas comuns

Uma falha comum na definição do escopo e comprometimento com tarefas é ignorar o débito técnico. O time de desenvolvimento tem de estar ciente de que em torno de 25% do seu tempo estará fazendo correções e ajustes.

Se o time ignorar o débito técnico, seja não deixando esta margem ou qualquer outra, mais cedo ou mais tarde terá problemas técnicos e sua produção cairá em sprints futuras.

Outra falha comum é na definição de tarefas. Quer você use User Stories ou não, jamais detalhe com uma granularidade muito fina o que terá de ser feito.

Como a responsabilidade dos detalhes de implementação cabe aos desenvolvedores, não há porque discutir e especificar isso abertamente dentro da Sprint Planning.

Nada impede, no entanto, que os desenvolvedores se reúnam após a Planning para uma reunião técnica de detalhamento. Planejar demais com antecedência gera desperdício.

Outra armadilha recorrente é subestimar a importância desse planejamento colaborativo e democrático. Alguns times nomeiam um líder para tomar as decisões por todos, desconsiderando a importância de suas opiniões individuais no processo de planejamento.

Concluindo, a Sprint Planning é uma cerimônia simples, mas que requer algum investimento de tempo prévio por parte do Product Owner e uma condução assertiva por parte do Scrum Master. Dessa forma, o time evitará as armadilhas.

Conhece alguma outra dica para o sucesso da sprint planning? Coloque nos comentários!

 Para entender melhor a necessidade das reuniões nos Métodos Ágeis, veja esse vídeo:

 

Sobre o autor

Robson Camargo, PMP, MBA, GWCPM, ASF é professor nos cursos de MBA das Principais Escolas de Negócio do País: FGV, Fundação Dom Cabral e FIA/USP com Certificação PMP – Project Management Professional emitida pelo PMI, MBA em Administração de Projetos pela FEA/USP e Master Certificate pela George Washington. Robson Camargo é autor do livro PM VISUAL e criador do Método PM VISUAL. Sua equipe realiza treinamentos e consultorias em empresas do Brasil e exterior. Robson Camargo está à frente da RC Robson Camargo – Projetos e Negócios, há mais de 11 anos.

As marcas PMP, PMI, PMBOK e a logomarca “REP” RegisteredEducationProvaider são marcas registradas do Project Management Institute, Inc.