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.

Artigos de eventos do Scrum

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Ру́сский, Việt Nam, 简体中文 and 繁體中文.

Leave a Reply

O seu endereço de email não será publicado. Campos obrigatórios marcados com *