Mesmo que não muito conhecidos no mundo ágil, há alguns artefatos do Scrum que podem ser empregados para expandir o campo de planejanento 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.
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. Este termo me despertou curiosidade. Após conferir as literaturas do Scrum, descobri que esse artefato realmente existe!
Diferença entre Pre-Planning e Planning
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 funcionalidade 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.
Pre-Planning na prática
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.
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!
Conclusão
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!
Fico por aqui, leitores.
Até a próxima semana!