A Sprint começa pelo planejamento, logo o Sprint Planning é o primeiro evento oficial do framework Scrum dentro da Sprint.
Essa reunião é realizada por todo o time Scrum, ou seja, Dono do Produto, Time de Desenvolvimento e Scrum Master, dividida em duas partes iguais, com tempo máximo de 4 horas cada parte (total de 8 horas) para uma Sprint de 30 dias (para sprints menores que 30 dias, normalmente o tempo da reunião é menor proporcionalmente) e aonde são respondidas duas questões chaves:
- O que será desenvolvido na Sprint?
- Como será desenvolvido?
Parte 1: “O que será desenvolvido na Sprint”.
Na primeira etapa, o Time de Desenvolvimento avalia as funcionalidades que poderão entrar na Sprint, conforme a prioridade dos itens definida pelo Dono do Produto. Então, o dono do produto poderá detalhar os itens de forma que o time de desenvolvimento possa compreendê-los e o time de desenvolvimento avaliará a complexidade e quantos itens caberão na Sprint.
As entradas para desta parte da reunião são:
- Os itens de backlog do produto, devidamente priorizados e detalhados no nível maior possível, para que sejam facilmente compreendidos pelo time de desenvolvimento;
- O último incremento do software em desenvolvimento;
- A capacidade projetada do time de desenvolvimento (sua produtividade em pontos); e
- A performance da última Sprint.
O detalhamento dos itens, normalmente é feito em formato de histórias de usuários, mas poderão ser casos de uso, especificação de requisitos ou simplesmente textos descritivos, cabe aqui a empresa ou o Time Scrum definir a melhor forma de descrever as necessidades do software.
Realizado o alinhamento entre o dono do produto e o time de desenvolvimento, é então definida as estimativas de complexidade para cada item selecionado. Essa complexidade, normalmente medida em pontos, é data pelo Time de Desenvolvimento. A técnica utilizada normalmente é o Planning Poker (não vou detalhar aqui como funciona, fica para um outro artigo).
Após as estimativas, o time de desenvolvimento seleciona os itens que acredita ser possível entregar na Sprint, sempre respeitando a prioridade definida pelo Dono do Produto, sempre tomando o cuidado para não selecionar itens além da capacidade de entrega do time na Sprint.
Por exemplo, se uma Sprint de 30 dias é possível entregar 20 pontos, a equipe não poderá exceder esse número. Se tiver já tiver selecionado 18 pontos e o próximo item tem 4 pontos, é melhor não pegar esse item, deixando-o para a próxima Sprint, do que pegar 22 pontos e não conseguir entregar esse item ou deixa-lo pela metade ou até mesmo sacrificar algumas etapas do desenvolvimento para entrega-lo. Durante a Sprint, se a equipe entender que poderia ter pego o item pois daria tempo, ela pode negociar com o Dono do Produto a adição deste item para a Sprint. Pense que acrescentar itens durante a Sprint é melhor do que ter que tirar itens depois de iniciar a Sprint.
Após definido os itens, suas estimativas de complexidade, é então definida a meta da Sprint. A meta da Sprint é um balizador, uma frase curta que indica o que será entregue na Sprint. Por exemplo: “Converter o sistema para rodar no banco de dados SQLServer” ou “permitir ao usuário realizar pedidos de venda”.
O importante desta fase da reunião, é definir o que fazer e não como fazer. Cabe também nesta reunião ao time de desenvolvimento orientar o dono do produto em quebrar itens do backlog em itens menores, caso eles sejam muito grandes para serem desenvolvidos em uma única Sprint ou que estejam difíceis de entender (itens menores, facilitam a compreensão). Porém atenção, esta reunião não é para ficar reordenando os itens do backlog do produto, esse é um trabalho que deve ser feito previamente, caso contrário a reunião de planejamento não será ágil e nem produtiva.
As saídas desta primeira parte serão:
- Itens do backlog do produto selecionados para a Sprint
- Estimativas dos itens selecionados para a Sprint
- Meta da Sprint estabelecida e acordada pelo Time Scrum.
Parte 2: Como será desenvolvido
Terminada a primeira parte, logo em seguida, começa a segunda parte da reunião, aonde a pergunta “Como será desenvolvido” será respondida.
Nesta etapa, a presença do dono do produto não é obrigatória, mas caso o time de desenvolvimento necessite tirar alguma dúvida, o mesmo deverá atender de prontidão, por isso, é normal (e recomendado) que ele permaneça na segunda parte.
Nesta etapa, o time de desenvolvimento deverá decidir como fará para desenvolver a funcionalidade dentro da definição de “Pronto”, ou seja, quais as tarefas necessárias, para construir os itens do backlog do produto, dentro dos critérios de pronto do projeto, que satisfaças as necessidades ou requisitos descritos nas histórias de usuário.
Neste momento, são discutidas todas as tarefas necessárias, como análise, criação de tabelas, design, layout de tela ou relatório, desenvolvimento, testes, tecnologia necessária, bibliotecas que poderão ser utilizadas, etc. Cada item do backlog do produto, serão desmembrados em pequenas tarefas que precisarão ser realizadas pelo time de desenvolvimento e não poderão ser terceirizadas.
Nesta reunião, não é necessário detalhar todas as atividades necessárias para a Sprint inteira, pois durante a Sprint, os itens a serem desenvolvidos poderão ser melhor detalhados. O importante é detalhar pelo menos as tarefas dos primeiros dias de trabalho e diariamente os demais itens.
Esse desmembramento dos itens de Backlog de Produto em tarefas menores gera o chamado Backlog da Sprint. Essas tarefas devem ser estimadas em horas e não deve exceder 8 horas (trabalho de 1 dia), caso contrário será mais difícil medir a evolução do time na busca da meta da Sprint, já que para medição são consideradas as tarefas completadas, não há percentual concluído da tarefa.
Também é possível neste momento, acionar especialistas ou consultores para ajudar no processo de entendimento de como fazer os itens. Por exemplo, acionar um DBA da empresa para ajudar a definir o banco de dados, um consultor de negócio para esclarecer um cálculo de imposto, algum técnico para falar sobre uma determinada biblioteca. Mas veja, são pessoas que ajudam nas definições, o time deverá ser capaz de construir a solução por completo, sem delegar ou repassar tarefas para esses profissionais que estão fora do time de desenvolvimento em questão.
Após as estimativas em horas das tarefas, o time de desenvolvimento conseguirá avaliar melhor o tempo necessário para desenvolver os itens do backlog do produto selecionados e verificar se realmente conseguirá entregar tudo na Sprint. Caso o time entenda que não conseguirá entregar tudo, este deverá acionar o Dono do Produto e negociar itens que poderão ser retirados da Sprint. O inverso também é possível, caso o time entenda que a complexidade é menor e que poderão ser acrescentados mais itens na Sprint.
O importante é que o Time de Desenvolvimento se comprometa com os itens selecionados e que realize todas as tarefas necessárias para que o item seja considerado pronto para o uso.
Ao final da reunião, o time de desenvolvimento deve ser capaz de apresentar ao Dono do Produto como será para converter o item do backlog do produto em incremento de software pronto.
Terminada a reunião, o time de desenvolvimento poderá dar inicio às atividades da Sprint, tão logo a reunião termine. Essa reunião, apesar de ser Time-Boxed, ela pode terminar antes das 8 horas, desde que o objetivo da mesma seja alcançado. O que não poderá ocorrer é ela ultrapassar as 8 horas.
Espero ter ajudado e que tenha ficado claro. Dúvidas? Poste nos comentários.
Até a próxima!