Projeto

Geral

Perfil

Ações

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 Adminaproximadamente 6 anos · 1 revisões