A reunião de revisão da Sprint tem um prazo de 4 horas.
- A equipe não deve gastar mais de 1 hora se preparando para a revisão da Sprint.
- O objetivo da revisão do Sprint é que o Time apresente ao Product Owner e aos stakeholders a funcionalidade que foi feita. Embora o significado de “pronto” possa variar de organização para organização, geralmente significa que a funcionalidade foi totalmente projetada e pode ser enviada ou implementada. Se “pronto” tiver outro
significado, certifique-se de que o Product Owner e as partes interessadas o entendam. - A funcionalidade que não está “pronta” não pode ser apresentada.
- Artefatos que não são funcionalidade não podem ser apresentados, exceto quando usados para dar suporte à compreensão da funcionalidade demonstrada.
Os artefatos não podem ser mostrados como produtos de trabalho, e seu uso deve ser minimizado para evitar confundir as partes interessadas ou exigir que elas entendam como funciona o desenvolvimento de sistemas. - A funcionalidade deve ser apresentada nas estações de trabalho dos membros da equipe e executada a partir do servidor mais próximo da produção – geralmente um servidor de ambiente de garantia de qualidade (QA).
- A revisão do Sprint começa com um membro da equipe apresentando a meta do Sprint, o Product Backlog comprometido e o Product Backlog concluído. Diferentes membros da equipe podem discutir o que deu certo e o que não deu certo no Sprint.
- A maior parte da revisão do Sprint é gasta com os membros da equipe apresentando a funcionalidade, respondendo às perguntas das partes interessadas sobre a apresentação e observando as alterações desejadas.
- Ao final das apresentações, os stakeholders são entrevistados, um a um, para obter suas impressões, quaisquer mudanças desejadas e a prioridade dessas mudanças.
- O Product Owner discute com as partes interessadas e a equipe o rearranjo potencial do Product Backlog com base no feedback.
- As partes interessadas são livres para expressar quaisquer comentários, observações ou críticas sobre o incremento da funcionalidade do produto potencialmente entregável entre as apresentações.
- As partes interessadas podem identificar a funcionalidade que não foi entregue ou não foi entregue conforme o esperado e solicitar que tal funcionalidade seja colocada no Product Backlog para priorização.
- As partes interessadas podem identificar qualquer nova funcionalidade que lhes ocorra à medida que visualizam a apresentação e solicitam que a funcionalidade seja adicionada ao Product Backlog para priorização.
Artigos de eventos do Scrum
-
- O que é Planejamento de Sprint?
- O que é Revisão de Sprint?
- O que é Sprint Retrospective Meeting em Scrum?
- O que é o Refinamento do Backlog do Produto?
- O que são Integração / Entrega / Implantação Contínua no Scrum?
- O que são eventos Time-boxed no Scrum?
- O que é Spike no Scrum?
- O que é o Planning Poker em Agile?
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Ру́сский, Việt Nam, 简体中文 and 繁體中文.