Planejamento ágil e a lei de retornos decrescentes

Quanto tempo deve-se gastar planejando um sprint? Quão detalhado deve ser esse planejamento? O Manual do Scrum de Ken Schwaber recomenda um time-box de oito horas para o planejamento de um sprint de um mês, e dessas oito horas apenas quatro devem ser usadas para estimativas. Para sprints menores, deve-se usar tempos proporcionalmente menores. Isto é, o planejamento de um sprint de duas semanas deve levar 4 horas, ou meio dia. O mesmo manual também diz que normalmente apenas 60 a 70% do backlog do sprint é conhecido durante o planejamento - o restante será discutido e definido durante a execução do sprint. Os problemas surgem quando se tenta desenrolar esses 40-30% que "faltam" durante a reunião de planejamento. O objetivo é justamente que essas definições surjam a partir da execução do trabalho e de discussões entre equipe e product owner no decorrer do sprint. Se isso não está acontecendo, deve-se buscar eliminar o problema na sua origem - identificar se o product owner está ausente ou omisso durante o sprint, ou se a equipe tem dificuldades de quantidade ou qualidade de comunicação interna - mas é perigoso cair na tentação de tentar antecipar toda a discussão que deveria ocorrer durante o sprint. Uma reunião de planejamento de sprint excessivamente longa cria um overhead desnecessário para cada sprint e não garante maior precisão nas estimativas das tarefas. Aqui entra em ação um conceito emprestado da economia chamado lei dos retornos decrescentes. Essa lei afirma que em um sistema de produção, existe um ponto a partir do qual o aumento de uma variável de entrada não produz um aumento proporcional na saída. Ou seja, se você gastar o dobro do tempo planejando a duração de uma atividade, a sua estimativa não será duas vezes mais precisa. Esse conceito fica muito claro no gráfico abaixo baseado no exemplo de Mike Cohn (Agile Estimating and Planning, 2006). Como em tudo na vida, o fundamental é o equilíbrio. A equipe precisa encontrar em que ponto nesse gráfico deseja estar - o ponto no qual fica confortável com relação ao trabalho a realizar no sprint, sem adicionar um overhead desnecessário a cada sprint com sessões demasiadamente longas de planejamento. Receio, inclusive, que sessões longas demais reduzam a precisão das estimativas devido ao cansaço e dispersão naturais em uma reunião que se torna muito cansativa. Há quem diga até que a quebra das histórias em atividades não é necessária para equipes experientes (A Cure for Task Estimation Obsession - Just Don't Do It, Alan Atlas), mas ainda gosto mais do caminho do meio...
Você não precisa de um grande esforço de projeto aqui, mas você precisa do suficiente para obter uma boa lista de tarefas. ....... Lembre-se que o objetivo não é projetar tudo que é necessário para a iteração, mas ajudar a reconhecer qual a melhor divisão em tarefas. Você fará outras sessões de design/projeto como parte da execução das tarefas.
Kent Beck and Martin Fowler, Planning Extreme Programming