Sprint Pre-Planning - André Celestino
27/01/2014 por André Celestino·Nenhum comentário
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!
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.
Você ainda não falou as diferenças…
Gosto de fazer um suspense, né? rsrs…
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.