Regras das Cerimônias do Scrum - Reunião de Revisão da Sprint

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.

Regras das Cerimônias do Scrum – Reunião de Revisão da Sprint

Artigos de eventos do Scrum

Leave a Reply Cancelar resposta