Planejamento de Sprint orientado por Velocidade
Existem duas abordagens fundamentais para planear um Sprint:
-
Sprint Planning orientado pela Velocity (considerando o volume médio de trabalho de uma equipa), e
-
Sprint Planning orientado pelo Commitment (considerando o que uma equipa acredita conseguir realizar num Sprint).
Planejamento de Sprint orientado por Velocidade
Aqui falamos sobre Sprint Planning orientado por velocidade. A quantidade de trabalho planejada para o próximo Sprint deve corresponder aproximadamente à dos Sprints anteriores. Isso pressupõe, naturalmente, que o tamanho da equipe permaneça mais ou menos o mesmo, que tarefas similares sejam realizadas nos Sprints, que os Sprints tenham aproximadamente a mesma duração, etc. Felizmente, desvios dessas condições podem ser facilmente identificados. Se, por exemplo, um Sprint durar apenas nove em vez de dez dias por causa de um feriado, a equipe já sabe disso antecipadamente.
Os passos individuais no Sprint Planning orientado por velocidade:
Descobrir qual foi a Velocity média do time nos Sprints anteriores.
Com base nessa Velocity, selecionar a quantidade correspondente de itens do Product Backlog.
Identificar as tarefas individuais das User Stories e avaliar se pode ser a quantidade certa de trabalho.
Estimar se essas tarefas exigem a mesma quantidade de trabalho que as dos Sprints anteriores.
Mas vamos analisar esses passos mais detalhadamente.
Passo 1: Determinar a velocity média de uma equipe
O primeiro passo no Sprint Planning orientado por velocity é determinar a velocity média de uma equipe. Algumas equipes ágeis orientam-se apenas pela velocity do seu último Sprint. Muitas equipes acreditam que esse é o melhor indicador do que pode ser alcançado no próximo Sprint. Isso não está errado, claro. No entanto, pode ser útil olhar um pouco mais para trás (se esses dados estiverem disponíveis).
Para isso, analisa-se a velocity dos últimos três a oito Sprints. A experiência mostra que assim é possível prever bastante bem os Sprints futuros. Naturalmente, não se deve exagerar e calcular a média dos últimos dez anos. Afinal, isso não diria nada sobre a velocity atual de uma equipe. Porém, se os dados de Sprints anteriores estiverem disponíveis, não se deve olhar apenas para o último Sprint.
Passo 2: Selecionar Product Backlog Items
Com base na velocity média recém-determinada, os membros da equipe podem então selecionar os itens para o próximo Sprint. Juntos, eles devem corresponder – pelo menos aproximadamente – à velocity média.
Neste ponto, o Sprint Planning orientado por velocity está basicamente concluído e pode ser finalizado em poucos segundos – assim que a equipe tiver selecionado os Product Backlog Items de acordo com sua velocity média, está pronto.
Passo 3: Identificar Tasks (opcional)
Muitas vezes, esse curto período para um Sprint Planning não é realmente suficiente. Por isso, as equipes podem adicionar um terceiro passo ao seu planejamento, no qual as tasks a serem executadas são identificadas.
Para isso, os membros da equipe discutem cada Product Backlog Item selecionado para o Sprint. Eles tentam identificar quais etapas de trabalho são necessárias para a conclusão dos itens. Claro que não é possível pensar em tudo, mas deve-se esforçar para considerar o máximo possível.
Depois disso, a equipe avalia se os itens selecionados e as tasks correspondentes preencherão o Sprint. De acordo com isso, alguns itens podem ser adicionados ou removidos do Sprint.
Algumas equipes encerram seu Sprint Planning agora, outras realizam ainda um último passo:
Passo 4: Estimar as Tasks (opcional)
Por fim, algumas equipes vão estimar quantas horas provavelmente precisarão para as tasks selecionadas. Com isso, podem verificar se planejaram a quantidade certa de trabalho.
Este texto é do blog de Mike Cohn e foi traduzido por nós para o alemão.
