Dicas para um Sprint Planning de sucesso

A Sprint Planning ou Reunião de Planejamento de Sprint é uma cerimônia simples dentro do processo ágil Scrum. Se você investir algum tempo prévio refinando o Product Backlog (tarefa principal do Product Owner) você conseguirá fazer uma Planning produtiva sem sombra de dúvida. Ajuda também evitar algumas más práticas que vou citar no artigo de hoje, que tem como objetivo enriquecer as informações sobre Sprint Planning existentes no Scrum Guide.

O propósito da Sprint Planning

Antes de começar a dizer o que fazer e o que não fazer quando o assunto é Sprint Planning, vale a pena relembrarmos qual o real propósito dela: alinhar o time de desenvolvimento e o Product Owner. Ambos precisam concordar no que será entregue como incremento de produto na próxima sprint e o time deve apresentar um plano de como irá trabalhar para que este incremento seja possível.

Se o Time Scrum possui um Product Backlog refinado e priorizado, o Time de Desenvolvimento será capaz de, juntos, ajustar o escopo da sprint à sua capacidade de produzir código, incluindo nessa previsão as ausências e impedimentos já previstos como férias de colegas, idas ao médico, etc. Geralmente essa conversa inicial para mensurar um escopo exequível e demais assuntos preparatórios dura entre cinco a dez minutos da etapa inicial da Planning, deixando todos alinhados e preparados para quebrar as tarefas macro em sub-tarefas que fiquem mais fáceis de mensurar na etapa seguinte (geralmente usando User Stories).

O Time de Desenvolvimento na Planning

Em primeiro lugar, é 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 quão disponíveis estarão para a próxima sprint. Jamais considere que 100% dos membros do time estarão disponíveis 100% do tempo e não esqueça de novos membros que possam estar entrando 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ável para cobrir possíveis ausências não previstas (doença, atrasos diversos, detalhes não previstos, bugs urgentes, etc).

Alguns times assumem uma postura confiante de que são 100% produtivos o tempo todo e isso leva-os a uma armadilha do ego que diminui a qualidade do trabalho, de vida e das relações entre os membros do time, que ficam cada vez mais reféns de metas impossíveis e inalcançáveis.

Em segundo lugar, 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 aqui ajuda bastante, pois dá uma noção mais clara de todas etapas que cada tarefa deverá percorrer para ser entregue de fato.

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, ajustes e refatorando código existente. 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 severos 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.

E por fim, uma 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. Isso leva a uma série de problemas, desde estimativas não condizentes com a realidade até problemas de comprometimento de quem se sentir lesado posteriormente com as decisões tomadas nesta ocasião.

O Product Owner na Planning

O papel do Product Owner dentro da Sprint Planning é trazer um Product Backlog refinado, priorizado e um objetivo muito claro. Assim como para manter um exército motivado para uma batalha, todos precisam saber pelo quê estão “lutando”. Esse objetivo cabe ao Product Owner definir e ele deve ser alcançável e mensurável. O P.O. deve ser “firme” na sua decisão de objetivo e ser capaz de responder as dúvidas de negócio relacionados ao incremento combinado.

Com isso em mente, entende-se que o Product Owner deve fazer o “dever de casa” antes de começar a Sprint Planning, para poder definir o objetivo da sprint, a prioridade das tarefas e se cercar do conhecimento necessário sobre o produto a ser desenvolvido do ponto de vista do business. E dentro desse dever de casa, uma falha comum que P.O.s cometem é o de assumir que todo o trabalho não entregue da sprint passada caberá nesse sprint além das novas tarefas que ele priorizou.

Não é porque algumas tarefas haviam sido aceitas na sprint anterior que você pode considerá-las como automaticamente aceitas nesta sprint. Além disso, elas consomem tempo e por não terem sido entregues na última sprint devem ser alvo de uma investigação para entender os motivos do ocorrido.

Outro ponto de atenção são as famosas “mudanças de última hora”. O P.O. jamais deve tentar empurrar tarefas que apareceram de última hora na Sprint Planning e menos ainda após ela. Cabe ao Scrum Master não permitir esse comportamento que pode arruinar a sprint. Se isso acontece com frequência, é sinal de que o Product Owner não está fazendo o seu trabalho direito.

Lembre-se: o foco do P.O. não é delegar as tarefas ao time, mas priorizá-las de modo a garantir o ROI e a entrega de valor ao cliente. Focar em quantidade nunca é a melhor solução.

Anti-padrões

O anti-padrão mais comum em Times Scrum são as sprints irregulares e elas já nascem assim em Sprint Plannings mal conduzidas. Um dos motivos disso acontecer são tarefas mal dimensionadas que não cabem dentro da Sprint e acabam arrastando seu término. Nenhuma tarefa deve entrar na sprint com duração maior do que alguns dias, pior ainda quando insistem em colocar tarefas com o mesmo tamanho da sprint. É problema na certa! Sempre quebre tarefas grandes em pequenas tarefas.

Outro anti-padrão comum de acontecer em Sprint Plannings mal sucedidos é o “over-commitment” ou excesso de comprometimento. Seja porque o time acaba pegando tarefas demais para si, seja por que ele sempre coloca todo o trabalho não finalizado da sprint anterior na sprint atual. Se sobraram tarefas da sprint anterior, é porque as tarefas foram mal estimadas em relação à capacidade do time. Isso deve ser discutido na Retrospectiva e não ser algo recorrente.

Ignorar a Definição de Pronto nas estimativas também é um erro recorrente nos times. Conforme o time vai amadurecendo, é comum que a Definição de Pronto vá ficando mais complexa e que tome mais tempo para que cada tarefa satisfaça-a. Tempo este que não pode ser ignorado sob hipótese alguma.

Concluindo, a Sprint Planning é uma cerimônia simples, mas requer algum investimento de tempo prévio por parte do Product Owner e uma condução assertiva por parte do Scrum Master para que o time inteiro não caia em alguma das armadilhas supracitadas. Uma ferramenta que pode ajudar a gerenciar o Product Backlog e deixar tudo preparado para a Sprint Planning é o Visual Studio Online, que ensino a usar neste post.

Conhece alguma outra dica para a sprint planning ou armadilha que deva ser evitada? Coloque nos comentários!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!