Mesmo que não muito conhecidos no mundo ágil, há alguns artefatos do Scrum que podem ser empregados para expandir o campo de planejamento e aperfeiçoar a precisão de uma Sprint.
Um destes artefatos é a Sprint Pre-Planning (Reunião de Pré-Planejamento), normalmente confundida com a Sprint Planning (Reunião de Planejamento), devido à semelhança no nome. Muitas empresas utilizam estes dois artefatos, mas não conhecem a distinção entre eles.
Imagem via Shutterstock
Já trabalhei em uma empresa que realizava duas cerimônias de planejamento: Sprint Planning 1 e Sprint Planning 2. Entretanto, apesar de se tratarem de uma sequência de reuniões, essas duas cerimônias apresentavam propósitos diferentes. Mais tarde, ao ler sobre Desenvolvimento Ágil no blog de uma empresa canadense, notei que eles também realizam as mesmas reuniões, mas denominam a primeira como Sprint Pre-Planning. Esse nome me despertou curiosidade. Após conferir as literaturas do Scrum, descobri que essa reunião realmente existe.
Qual a diferença entre as duas?
Bem, sabemos que a Sprint Planning consiste em definir e atribuir as user stories (histórias do cliente) para cada membro da equipe, certo? Porém, antes disso há uma etapa de seleção das novas funcionalidades e um cálculo do tamanho de cada uma baseado em story points e/ou na estimativa da equipe. Na maioria dos casos, essas duas etapas (seleção e atribuição) são realizadas em reuniões diferentes para não comprometer o tempo dos membros. A equipe, então, decide “quebrar” a reunião em duas partes para definir o Sprint Backlog, quando, na verdade, ela está elaborando duas reuniões distintas: a Sprint Pre-Planning e a Sprint Planning.
A Sprint Pre-Planning pode ser resumida na atividade de determinar quantas e quais funcionalidades serão incluídas na próxima Sprint. Nessa reunião, o Product Owner deve estar presente para selecionar as funcionalidades enquanto a equipe estima o tempo e esforço necessário para cada uma delas. Além disso, a equipe também pode identificar os pré-requisitos e os impactos que as novas funcionalidades irão causar no software em desenvolvimento, bem como “trocar” ou excluir certas funcionalidades que possam afetar o prazo ou o escopo. Só um adendo: quando digo “equipe”, me refiro também ao Scrum Master.
Como essa discussão das funcionalidades é conduzida?
Para que todos possam visualizar e discutir sobre cada funcionalidade, a equipe pode utilizar um quadro, geralmente conhecido como Planning Board. Este quadro contém apenas duas colunas: Product Backlog e Sprint Backlog. Ao iniciar a reunião, a primeira coluna deverá conter todas as funcionalidades pendentes a serem implementadas no software (representadas por post-its), enquanto a segunda coluna estará vazia. O objetivo é preencher a segunda coluna até o final da reunião com o que será desenvolvido na próxima Sprint. Para isso, o Product Owner se encarrega de selecionar as funcionalidades (arrastando os post-its da primeira para a segunda coluna), enquanto a equipe revisa e discute as estimativas.
Caso muitos post-its sejam arrastados para a segunda coluna, e equipe deve se manifestar para convencer o Product Owner de que a Sprint Backlog se encontra bastante extensa. Se necessário, a equipe ainda pode apresentar métricas de produtividade como argumento para a discussão.
O que é gerado com essa reunião?
Uma vez concluída, a Sprint Pre-Planning fornecerá uma estrutura definida da próxima Sprint Backlog, de forma que o planejamento das implementações, atribuições e outros aspectos técnicos possam ser designados com maior precisão na reunião seguinte, na qual finalmente chamamos de Sprint Planning!
Antes de finalizar o artigo, gostaria de fazer uma observação, aliás, uma sugestão. No início do artigo, mencionei que é possível ocorrer duas reuniões de planejamento (Sprint Planning 1 e 2), visto que, em algumas empresas, a equipe é tão grande que apenas uma cerimônia não é o suficiente, levando a equipe a dividir o planejamento em duas partes. Neste caso, eu sugiro que uma decomposição da equipe seja considerada, formando subequipes (também denominadas “células de trabalho”) regidas por Scrum Masters diferentes. Essa é uma premissa do framework Large-Scale Scrum, introduzida por Craig Larman e Bas Vodde no livro Practices for Scaling Lean & Agile Development, de 2010. Vale a pena conferir!
Mais uma vez, obrigado pela atenção!
Abraço!
Publicado originalmente no blog SubRotina
