Planejamento de Sprint — quanto tempo é o ideal?

Participei de uma discussão há um tempo sobre a cerimônia de planejamento e refinamento de histórias, então realizada toda segunda-feira (definir a meta da semana, por assim dizer). Resumindo bastante a história, essa conversa gravitou entre dois grandes temas: qual o tempo ideal para essa cerimônia e qual o nível de detalhes que a história precisa para que seja possível começar a trabalhar em seu desenvolvimento. Para evitar estender demais o post, vou me restringir ao primeiro tema nesse artigo, e deixar o segundo para um breve futuro.

Um pouco do contexto do time, no momento em que comecei a fazer parte dele: as sprints eram de 2 semanas, no primeiro dia era feita a reunião de planejamento / refinamento, na qual as histórias eram quebradas em tarefas e, daí, estimativas em Story Points.

Minhas impressões

A quebra de histórias, para mim, era um compromisso com uma abordagem de implementação bastante prematuro, visto que tudo o que estava em desenvolvimento no momento era muito novo (logo: havia muito pouca informação sobre o que de fato precisava ser feito); e a estimativa por pontos, para mim, era algo a ser abolido tão cedo quanto possível, principalmente por já ter presenciado (mais de uma vez) discussões caminharem para “que número vai pra essa história?”, e não sobre o que era, qual o seu valor, dificuldades associadas, enfim, discussões que pouco contribuíam para a história de fato!

Mudanças

Decidimos, então, não fazer mais as estimativas por pontos, e, seguindo um conselho escrito como um dos princípios do Lean, a quebra de tarefas foi então, postergada para o momento de desenvolvimento (ou, “último momento responsável”, para ficar ainda mais aderente ao material de referência). Essas duas vieram mais ou menos ao mesmo tempo — outra mudança no processo que ocorreu apenas algum tempo depois, foi reduzir o período de uma sprint para uma semana, com o objetivo de acomodar melhor as frequentes mudanças de prioridade que costumavam surgir no decorrer das sprints.

Pergunta: é um problema mudar prioridades durante uma Sprint?

Levando ao pé da risca o Scrum Guide, pode sim ser um problema já que, segundo o material, durante uma sprint não deve haver alterações de escopo que ponham em risco o objetivo da Sprint. Em minha leitura, essa regra do Scrum bate de frente com um dos valores do Manifesto Ágil — “Responder a mudanças mais do que seguir um plano” — ainda que seja um plano de curto prazo (para uma sprint, seja qual for sua duração); além de ir de encontro também a um dos princípios: “Mudanças nos requisitos são bem-vindas,mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente”.

Quanto tempo, então?

Apesar da importância de trazer Scrum Guide e Manifesto Ágil para a discussão, voltemos ao cenário do time — que estava, então, com uma grande dúvida: quanto tempo da sprint (nesse cenário, uma semana) dedicar para planejamento? Admito que gosto de períodos tão curtos quanto possíveis; o que já seria um motivador a levar a reunião para 1h, no máximo (talvez mais uma, se necessário algum detalhamento mais específico). O mais preocupante pra mim, no entanto, era tentar chegar nesse “número mágico” (quanto tempo), sem definir ao certo qual o objetivo esperado (e, novamente, vou evitar entrar no tema nível de detalhes necessário numa história).

Em algum momento essa discussão ficou um pouco mais… calorosa :) — inclusive porque houve uma proposta de voltar ao tamanho original da sprint, de duas semanas, para, assim, justificar usar um dia inteiro (a primeira segunda, no caso) para planejamento. Bom, se você considera essa como uma opção para seu time, saiba desde já que discordo, respeitosamente :) — voltando, então, ao ponto central: sou favorável a reuniões de planejamento ou refinamento tão curtas quanto possível, por esses motivos:

1. Capacidade de atenção: embora não haja realmente um consenso, reuniões com duração maior do que 1h já são um sério risco a desvio de foco por pelo menos uma parte do público presente (para maiores detalhes, alguns relatos nesse link e nesse outro);
2. Com menores períodos de iteração, a tendência é que o backlog de uma sprint (daqui pra frente chamado de “lote”) seja proporcionalmente menor também, e reduzir o tamanho do lote é desejável porque diminui tempo de coordenação (overhead) e também acelera o feedback (lembrando: o objetivo da iteração é ter entrega de software o quanto antes, e usar esse feedback como informação para tomar as decisões na iteração seguinte);
3. Projeções se tornam exponencialmente mais fáceis para horizontes de planejamento menores, e escopos menores tendem a desenvolvimento mais rápido (diminuindo ainda mais esses horizontes) — o ganho ao fazer isso é conseguir dar mais previsibilidade para a capacidade de entrega do time;
4. Trazendo outro princípio do Manifesto Ágil à tona, também vemos a preferência por tempos menores de iteração: “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo”;
5. “Planos são inúteis, mas planejar é indispensável”* — o objetivo do planejamento não é ter um documento/compromisso imutável, mas sim uma perspectiva de quais são as atividades que devem pertencer ao próximo lote, com o conhecimento disponível no momento. E aqui é importante ressaltar que esse conhecimento é provavelmente bastante impactado por ruído (informações incorretas, detalhes ainda não conhecidos, enfim), razão pela qual não só é aceitável postergar algumas decisões como é de fato mais vantajoso que o time assim o faça!
6. Num exercício de hipótese: o que acontece se passamos um dia inteiro em planejamento e no dia seguinte a prioridade da iteração muda? O resultado desse planejamento corre um risco alto de ficar defasado. Conhecimento gerado e não usado, na melhor das hipóteses, gera retrabalho, já que o time deverá se debruçar novamente o assunto para lembrar das decisões e porque foram tomadas, e no pior cenário, se perde — em qualquer um dos cenários há algum nível de desperdício. Trazendo à tona os princípios de Desenvolvimento de Software Lean, o primeiro (e também considerado fundamental) é justamente eliminar desperdício;
7. Mais tempo para planejar não implica em maior sucesso; esse gráfico, no livro Agile Estimating and Planning, está na verdade num capítulo sobre estimativas; aplicando o mesmo conceito para planejamento de modo geral: o tempo (ou esforço) dispendido em qualquer uma dessas atividades não garante precisão de estimativa ou qualidade do plano — de fato, depois de um ponto ótimo, tempo ou esforço adicionais podem ser (e frequentemente são) contraproducentes

Precisão de estimativa em função de esforço para realizá-la

Conclusão

Como dito no início do artigo, quis deliberadamente deixar para um momento posterior o tema nível de detalhes para uma história (ou, se preferir, dicas para o que deve ser um bom “Definition of Ready”). Espero que a discussão feita até aqui possa ajudar de alguma forma!

Muito obrigado pela atenção e por seu tempo :)

Referências

1. Manifesto Ágil
2. Scrum Guide
3. Knowledge Decays. Here's How Your Organization Can Keep Up
4. COHN, Mike. Agile Estimating and Planning, Addison-Wesley Professional, 2005
5. POPPENDIECK, Mary and POPPENDIECK, Tom. Lean Software Development: An Agile Toolkit, Addison-Wesley Professional, 2005
6. REINERTSEN, Donald G. Principles of Product Development Flow, Celeritas Publishing, 2009

Citação

• “In preparing for battle, I have always found that plans are useless, but planning is indispensable.” (Dwight D. Eisenhower)

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa Tripulação! Você pode conferir nossas vagas aqui.