esta postagem foi publicada originalmente em 11 de janeiro de 2017 e atualizada mais recentemente em 7 de fevereiro de 2021.
o framework Scrum de gerenciamento de projetos é baseado em quatro reuniões ágeis básicas, ou seja, cerimônias: reunião de planejamento de Sprint, Stand-up diário, revisão de Sprint e retrospectiva de Sprint.
o planejamento de primavera é parte integrante da configuração de sua equipe para um Sprint bem-sucedido. Sem uma quantidade adequada de trabalho e compreensão de seus objetivos, um Sprint pode descarrilar rapidamente. Felizmente, essas reuniões são bastante fáceis de dominar depois de aperfeiçoar alguns processos-chave de planejamento.
se você nunca executou uma reunião de planejamento de Sprint, aqui está o seu guia.
selecionando itens do Backlog
no início de cada Sprint, o Product Owner, Scrum Team e Scrum Master se reúnem para organizar o trabalho para o próximo Sprint.
primeiras coisas primeiro! Todo mundo analisa o Backlog do produto, enquanto o proprietário do produto fornece informações sobre os objetivos e o contexto de cada item.
em seguida, a equipe Scrum seleciona quantos itens do Backlog do produto desejam concluir durante o Sprint. Como os itens do Backlog aparecem em ordem de importância, a equipe do Scrum deve escolher os itens no topo do Backlog.
esta dinâmica cria um equilíbrio entre Scrum Team e Product Owner. O Product Owner cria / organiza o Backlog e escolhe o que é mais importante. Mas a equipe Scrum decide exatamente com quanto trabalho eles podem se comprometer em um determinado Sprint. O Scrum Master facilita esse processo e mantém o equilíbrio de poderes.
esse processo garante que cada membro da equipe se sinta capacitado em relação ao seu próprio trabalho. Além disso, garante um compromisso mais sincero e maior responsabilidade da equipe.
há uma exceção a esta regra: a equipe só pode puxar itens de mais adiante no Backlog se fizer mais sentido com o outro trabalho em andamento naquele Sprint. Ou seja, se o trabalho for logicamente feito mais rápido porque é muito semelhante a outros itens.
estimando a disponibilidade da equipe
Antes de selecionar itens do Backlog, a equipe também é responsável por estimar quanto tempo cada Membro tem para o trabalho relacionado ao Sprint. A maioria dos dias dos membros da equipe não será dedicada inteiramente ao trabalho de Sprint. O tempo disponível deve ser determinado pelo dia de trabalho médio menos o tempo que eles esperam gastar fazendo outro trabalho como manutenção, participando de reuniões, pausas para almoço, e-mail e correções de bugs.
realisticamente, a maioria das pessoas tem de quatro a seis horas por dia disponíveis para o trabalho de Sprint.
estimando o tempo para completar cada item do Backlog
a segunda peça do quebra-cabeça está descobrindo quanto tempo cada item em si levará. Isso requer que o proprietário do produto e a equipe trabalhem juntos para dividir cada item em tarefas individuais. Você pode então atribuir a essas tarefas um tempo estimado para concluir. O tempo para completar todos os itens selecionados para o Sprint não pode exceder o tempo disponível na equipe.
cada tarefa e estimativa de tempo é registrada em um documento chamado Sprint Backlog. Esta é uma versão do Backlog que é relevante apenas para o Sprint atual.
auto-organização
uma vez que sua equipe tenha finalizado a disponibilidade de membros, bem como o tempo necessário para cada tarefa, a equipe começa a determinar quem completará cada item por voluntariado.
os itens nunca são “atribuídos” aos membros da equipe. Fatores como sequenciamento podem significar que faz mais sentido para uma pessoa obter um certo agrupamento de itens. Mas você nunca atribui tarefas contra a vontade do trabalhador.
a carga de trabalho final de cada indivíduo deve ser razoável e justa. O Product Owner desempenhará um papel importante em ajudar a equipe a entender completamente cada item para que eles possam quebrar as coisas da maneira mais uniforme possível.
acompanhamento do progresso
no final da reunião, o Backlog do Sprint conterá uma lista de tarefas atribuídas com estimativas de tempo.
muitas equipes usam um quadro Kanban (físico ou digital) para rastrear visualmente cada item à medida que ele se move no Sprint. Categorias simples como fazer, em andamento, revisão de código e Concluído podem ajudar a equipe a ter uma visão rápida de como os itens do Sprint estão progredindo.
outras equipes usam software de gerenciamento de projetos dedicado, que pode ajudá-los a rastrear Sprints do início ao fim com recursos visuais como gráficos Gantt e Burndown. Status de Tarefas como aberto, em andamento, resolvido e fechado mantêm o progresso transparente para todos os membros. E rastrear dados como tempo estimado e tempo real pode ajudá-lo a estimar melhor o trabalho no futuro.
durante o Sprint
uma vez que a equipe Scrum comete e o Sprint começa, o Product Owner não pode alterar os requisitos ou adicionar novas solicitações. Essa pessoa não pode fazer alterações até o início do próximo Sprint.
há uma exceção clara a esta regra: você pode fazer alterações no meio do sprint se um fator externo alterar as prioridades de forma tão drástica que os resultados do Sprint seriam um desperdício se continuassem. Isso raramente acontece, mas caso ocorra, a equipe interromperia todo o trabalho e iniciaria o processo de planejamento do Sprint do zero. O proprietário do produto só deve recorrer a essa interrupção maciça em circunstâncias extremas.
existem dois efeitos positivos de tornar os Sprints não mutáveis. Primeiro, proteger a equipe de mudanças e adições no meio do Sprint cria um ambiente de trabalho mais positivo. Os membros da equipe se sentirão confiantes em sua capacidade de concluir seu trabalho e fazê-lo bem.
em segundo lugar, incentiva o Product Owner a priorizar seu Backlog com o máximo cuidado. Eles são mais propensos a fazer sua devida diligência antes de empurrar um item para o topo da lista.
com o passar do tempo, as equipes melhoram na estimativa de quanto tempo os itens levam, prevendo problemas e colaborando entre si. Usando esse planejamento estruturado de Sprint, os proprietários de produtos podem ter certeza de que suas equipes estão comprometidas e capazes de fazer o trabalho.
adaptando-se às mudanças
embora os Sprints quase nunca devam ser interrompidos, isso não significa que a mudança não seja bem-vinda dentro da estrutura Scrum. Pelo contrário, mudanças no Backlog principal podem ocorrer a qualquer momento. O proprietário do produto tem liberdade para fazer quaisquer adições, exclusões ou modificações necessárias antes do próximo Sprint.
quando as equipes abordam a mudança dessa maneira, ela se torna uma parte responsável do processo e não é Mais vista como causa de estresse ou motivo de falta de prazos.
após o sprint
o processo ágil é cíclico. No entanto, muitas vezes você optar por executar suas reuniões de planejamento de primavera, você sempre vai voltar para eles para iniciar o processo todo. Quanto mais vezes sua equipe passou por isso, mais suave será cada ciclo.Além de concluir o projeto ou tarefas em mãos, seu Sprint não foi totalmente bem-sucedido, a menos que você tenha aprendido algo como uma equipe com ele. Esta próxima etapa do processo em que você se moverá é a retrospectiva do Sprint. Envolveu a análise de tudo o que você acabou de realizar e o que poderia melhorar da próxima vez. Para obter uma vantagem sobre algumas das técnicas possíveis que você e sua equipe podem usar, comece a estudar antes de terminar seu Sprint. Um Scrum Master capaz sabe exatamente cada etapa do processo.
Considerações Finais
a reunião de planejamento do Sprint geralmente dura algumas horas quando executada corretamente. Os compromissos assumidos exigem um pensamento e deliberação cuidadosos. Você deve permitir que sua equipe tenha o tempo necessário para planejar completamente o sucesso.
manter suas tarefas organizadas e transparentes tornará o rastreamento do processo muito mais fácil, portanto, considere investir em um software de gerenciamento de projetos dedicado se sua equipe ainda não estiver. Não apenas uma ótima ferramenta de gerenciamento de projetos economizará tempo e esforço, mas também tornará mais fácil obter insights do processo quando você estiver pronto para mergulhar em sua retrospectiva.
