By Está começando na área e não tem muita ideia do que acontece durante os eventos Scrum? Você já leu o Scrum Guide, porém não consegue aplicar os conceitos na prática? Conhece os eventos, mas está procurando novas formas de melhorar as reuniões do time? Então se liga na série de publicações sobre os eventos Scrum que vem por aí.
Combinarei conceitos definidos no Scrum Guide com a prática, minha experiência empírica facilitando eventos Scrum durante alguns anos em diversos times e empresas. A estrutura do checklist que eu utilizo é a seguinte:
- Fundamentos: parte conceitual
- Entradas: aquilo que você precisa certificar que seja atendido antes de iniciar o evento
- Processo: principais passos e atividades para a execução do evento
- Saídas: o que é esperado ao final da reunião
- Time-box: tempo de duração sugerido
O primeiro de quatro posts é sobre a Sprint Planning.
Fundamentos
“A Sprint Planning inicia a Sprint ao definir o trabalho a ser realizado na Sprint. Este plano resultante é criado pelo trabalho colaborativo de todo o Scrum Team.” (Scrum Guide)
A Sprint Planning é o momento onde o time define o Sprint Backlog com base nas prioridades do Product Backlog e de acordo com a capacidade do time.
💡 Esse é também o momento onde o time define COMO o trabalho selecionado será realizado.
A Sprint Planning aborda os seguintes tópicos:
- Por que esta Sprint é valiosa?
O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual.
- O que pode ser feito nesta Sprint?
Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual.
- Como o trabalho escolhido será realizado?
Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definition of Done (DoD).
Entradas
Processo
- PO apresenta as prioridades e objetivos de negócio
- PO e DEVs selecionam os incrementos do Product Backlog (PBIs) e adicionam no Sprint Backlog
- PO e DEVs definem os Sprint Goals, de preferência no formato SMART (S – Specific, M – Measurable, A – Achievable, R – Relevant, T – Time-boxed)
- DEVs revisam a sua capacidade (considerar horas disponíveis, feriados, férias, etc.)
- DEVs revisam a prioridade dos itens no Sprint Backlog (alguma dependência? Alguma tarefa precisa ser concluída antes de outra?)
- DEVs revisam cada item e planejam o que precisa ser feito para concluí-las (criar sub-tasks, check-list, testes, etc.)
- PO ou DEV (ou qualquer outro membro do time) inicia a Sprint no Scrum board do time
Saídas
- Sprint Backlog criado
- Sprint Goals definidos
- Plano de trabalho elaborado
- Sprint iniciada
Time-box
Duração máxima de 4 horas para uma Sprint de duas semanas (Scrum Guide).
Na prática, 2 horas podem ser um bom começo: A primeira hora para debater sobre o valor da Sprint e entender o que pode ser feito, e a segunda hora para o time planejar como o trabalho escolhido será realizado.
⚠️ Não existe bala de prata! Esse é um guia que pode funcionar na íntegra em algumas situações enquanto em outras apenas alguns elementos serão utilizados. Apesar das atividades do processo estarem listadas em sequência, elas nem sempre acontecem na ordem sugerida. É importante fazer a leitura adequada em cada contexto para otimizar ao máximo o tempo com o time e a eficiência desse evento Scrum.
By 
