2.1 Planejamento da Sprint¶
A reunião de Planejamento da Sprint (Abertura da Sprint) é composta de duas fases: planejamentos tático e operacional.
2.1.1 Planejamento Tático¶
Nesta fase, o Dono do Produto apresenta os objetivos da sprint e as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas, após a reunião, na fase chamada de Planejamento Operacional.
Para cada item do Backlog da Sprint, é necessário obter do Dono do Produto a descrição e a definição de pronto do item, assim não há dúvidas na hora de receber o produto previsto no item de trabalho planejado. Além disso, para cada item do Backlog, o Líder de Projeto (que é o responsável pelo planejamento) deve associar a release do Produto à qual o Projeto está vinculado (com isso, o gráfico de Burnup é gerado automaticamente).
No campo Descrição do item de backlog, deve-se incluir uma pequena descrição do item e a definição de pronto do item (o critério que será usado para aceitar o item ao final da sprint). É importante que essa definição leve em conta as descrições de produto pronto e de item preparado do PES (ver item 2.1.2 a seguir) e a visão do Dono do Produto, pois ele é quem aceita ou recusa as entregas da sprint, e que seja um critério facilmente verificável durante a reunião de encerramento da sprint. A emissão do Termo de Aceitação da Sprint deve ser realizada imediatamente após a reunião de encerramento e depende grandemente da definição objetiva da descrição e da definição de pronto.
2.1.2 Planejamento Operacional¶
Nesta fase, a equipe se encontra separadamente para conversar sobre o que ela escutou, decidir com quanto ela pode se comprometer a fazer na Sprint e quebrar as funcionalidades em tarefas. Em alguns casos, haverá negociação com o Dono do Produto, mas será sempre responsabilidade da equipe determinar com quanto ela será capaz de se comprometer.
É muito importante que os itens de backlog priorizados já tenham sido preparados antes da reunião. Itens que chegam à reunião sem detalhes suficientes podem colocar toda a sprint em risco.
Definição de produto preparado:
- Trabalhado em sessões de Refinamento do Backlog
- Estimado
- Pequeno o suficiente (idealmente, estimativa não superior a 8 pontos de história)
- Com critérios de aceitação (apresentados como cenários) definidos
Definição de produto pronto: definição expressa por meio de funcionalidades desenvolvidas em cada Sprint com 100% de completude, demonstrado por:
- Atendimento aos critérios de aceitação (apresentados como cenários) da história de usuário
- Código completo
- Testes unitários escritos e executados com sucesso (conforme cobertura dos testes definida na OS)
- Teste de integração executado com sucesso
- Documentação escrita
- Aprovação do dono do produto
Atualizado por Redmine Admin há aproximadamente 6 anos · 1 revisões