Um guia aprofundado sobre como inspecionar os resultados da Sprint, colaborar com stakeholders, aprender com feedback e mudanças no ambiente, adaptar o Product Backlog e evitar o erro comum de transformar a Sprint Review em uma demonstração, reunião de aprovação ou etapa de liberação.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o propósito da ; como os stakeholders e o inspecionam resultados e mudanças no ambiente; como o feedback influencia o valor e o ; como surgem adaptações futuras; e por que a é uma sessão de trabalho, e não uma apresentação, demonstração, cerimônia de aprovação ou etapa obrigatória para liberar valor.
Introdução: a é o ponto em que a realidade do produto encontra a direção do produto
Uma é valiosa quando o produto muda a conversa - e não quando a conversa apenas celebra o produto.
Em muitas organizações, a é tratada como o momento do time no palco. preparam slides, ensaiam uma demonstração, apresentam funcionalidades concluídas, respondem a algumas perguntas, recebem elogios e encerram a reunião. O evento pode parecer profissional e, ainda assim, deixar de cumprir quase completamente o propósito do .
O Scrum Guide atual define a como uma oportunidade para inspecionar o resultado da e determinar adaptações futuras. O apresenta os resultados de seu trabalho aos principais stakeholders, discute-se o progresso em direção ao , analisam-se mudanças no ambiente e todos colaboram para decidir o que fazer em seguida. O pode ser ajustado para aproveitar novas oportunidades.
Isso torna a um dos momentos mais importantes de aprendizado sobre o produto no . Um pode ordenar o backlog com base no melhor conhecimento disponível, os podem construir um Done e o pode perseguir um significativo; ainda assim, parte do valor permanece incerta até que pessoas reais inspecionem o que ocorreu e comparem o resultado com um ambiente em constante mudança.
Por isso, o reúne em uma mesma sessão de trabalho as pessoas que criam o produto e as pessoas afetadas pelo valor que ele gera. Stakeholders não participam apenas para assistir. Eles contribuem com conhecimento de mercado, necessidades de clientes, informações regulatórias, preocupações operacionais, oportunidades de negócio e feedback. O contribui com o real, evidências da e sua compreensão do progresso em direção ao .
Historicamente, versões anteriores do Scrum Guide usavam uma linguagem mais detalhada sobre demonstrar o trabalho concluído. Esse histórico contribuiu para o apelido comum " Demo". O Scrum Guide 2020 enfatiza deliberadamente um propósito mais amplo e alerta explicitamente o para não limitar a a uma apresentação. O evento é uma sessão de trabalho voltada à inspeção e à adaptação.
Para a preparação para a , essa diferença é extremamente importante. Muitas respostas incorretas soam familiares: o aceita ou rejeita o trabalho; stakeholders aprovam uma liberação; demonstram cada ticket; o conduz uma apresentação; ou nada pode ser disponibilizado antes da . Nenhum desses padrões define o evento no atual. O modelo mental correto é mais simples e mais poderoso: inspecionar o resultado, discutir mudanças e colaborar sobre o que fazer em seguida.
O propósito oficial: inspecionar o resultado e determinar adaptações futuras
O propósito da é inspecionar o resultado da e determinar adaptações futuras. Essa formulação posiciona o evento diretamente dentro do sistema empírico do .
Inspeção significa observar a realidade, e não apenas o plano original. Qual utilizável existe? O que foi aprendido durante a ? O que aconteceu com clientes, concorrentes, tecnologia, regulamentação, operações ou estratégia de negócio? O progresso em direção ao aumentou? Quais hipóteses se tornaram mais fortes ou mais fracas?
Adaptação futura significa que o evento deve influenciar o que acontece depois. Se stakeholders participam, assistem a uma demonstração e vão embora enquanto o permanece inalterado e nenhuma nova decisão é considerada, o evento pode ter produzido informação sem produzir adaptação.
A , portanto, não é uma retrospectiva sobre como o time trabalhou. Esse é o propósito da . A Review inspeciona o resultado do produto e seu ambiente. A Retrospective inspeciona a qualidade e a eficácia da forma de trabalho do .
O evento também não é um relatório de status. Um relatório de status pergunta se o trabalho planejado foi concluído. A pergunta o que o resultado significa para o produto e o que deve acontecer em seguida.
Âncora para a
= inspecionar o resultado da + determinar adaptações futuras.
Inspecionar o resultado, e não apenas a atividade concluída
O usa deliberadamente a palavra outcome (resultado) em vez de output (saída ou entrega). Output é aquilo que o time produziu: funcionalidades, interfaces, experimentos, alterações de API, documentos, hardware ou outros incrementos. Outcome diz respeito ao significado desses resultados no contexto do produto.
Uma funcionalidade pode estar Done e, ainda assim, gerar pouco valor. Clientes podem ignorá-la. Uma melhoria de desempenho pode gerar mais valor do que uma funcionalidade visível. Um pequeno experimento pode invalidar uma ideia cara e economizar meses de investimento. A cria espaço para interpretar esses resultados.
O é central porque torna o produto inspecionável. Stakeholders devem conseguir examinar um estado real e utilizável, em vez de relatórios de "percentual concluído", mockups que não representam o produto real ou afirmações em PowerPoint sobre progresso.
A Review também pode incluir evidências quantitativas: uso, tempo de resposta, conversão, tendências de defeitos, sinais de suporte ao cliente, métricas operacionais, resultados de experimentos ou outras evidências de produto. O não prescreve métricas, mas o e o devem buscar informações que melhorem as decisões sobre o produto.
É por isso que uma demonstração tecnicamente impressionante ainda pode resultar em uma fraca. Se o grupo nunca discute se o resultado altera a direção do produto, a principal oportunidade de aprendizado foi desperdiçada.
Os principais stakeholders participam da inspeção - não são uma plateia
O apresenta resultados aos principais stakeholders, mas a relação não deve se parecer com a de artistas e espectadores. Stakeholders fazem parte da conversa de inspeção e adaptação.
Stakeholder é qualquer pessoa ou grupo com interesse relevante no sucesso ou nas consequências do produto. Conforme o contexto, isso pode incluir clientes, usuários, executivos, vendas, suporte, operações, jurídico, compliance, marketing, parceiros, reguladores, finanças ou outros times.
Os stakeholders adequados variam de acordo com o e o resultado da . Um time de produto que trabalha com fraude em pagamentos pode precisar de stakeholders de risco e operações. Um produto de serviço público pode precisar de cidadãos, especialistas em políticas públicas e operadores do serviço. Uma plataforma para pode precisar de engenheiros que consomem a plataforma.
A participação dos stakeholders melhora a transparência porque as hipóteses são confrontadas com múltiplas perspectivas. podem acreditar que um fluxo é simples enquanto usuários o consideram confuso. Um executivo pode acreditar que uma oportunidade é urgente enquanto evidências operacionais mostram um risco de confiabilidade maior. Um stakeholder de compliance pode revelar uma mudança regulatória que altera o .
O permanece accountable pelo . A colaboração com stakeholders não transforma a em um comitê que vota a . Stakeholders influenciam por meio de evidências e discussão; o integra essas contribuições às decisões de produto.
Colaboração, não controle por comitê
Stakeholders devem influenciar decisões de produto com evidências e feedback, mas a accountability pelo permanece com o .
Feedback: útil quando muda a compreensão
O feedback é um dos benefícios mais visíveis da , mas nem todo feedback tem o mesmo valor. "Ficou bom" gera pouco aprendizado. Um feedback forte revela algo sobre valor, usabilidade, risco, oportunidade ou sobre o ambiente.
As melhores Reviews facilitam feedback ao oferecer aos stakeholders algo concreto para inspecionar. Uso real, fluxos realistas, evidências de produção ou dados significativos do produto geram discussões mais ricas do que slides polidos.
O feedback pode confirmar a direção atual. Pode sugerir um novo . Pode revelar que um item existente vale menos do que se imaginava. Pode levar o a mudar a ordem, dividir um item, remover trabalho ou buscar uma nova oportunidade.
O feedback não deve ser interpretado como teste de aceitação realizado por stakeholders. Done é determinado pela , e não por aplausos de stakeholders ou pela aprovação do durante a Review. O feedback pode alterar o trabalho futuro, mas não define retroativamente se o estava Done.
O feedback também pode chegar ao longo de toda a . O não exige que o time espere pela para falar com usuários ou liberar um . A Review é uma oportunidade formal e recorrente de reunir evidências atuais, não o único momento em que o aprendizado é permitido.
Mudanças no ambiente: o produto não existe no vácuo
O Scrum Guide atual orienta explicitamente o e os stakeholders a revisar o que mudou no ambiente. Isso é fundamental porque o valor do produto é relativo ao contexto.
Um concorrente pode lançar uma nova capacidade. Uma regulamentação pode mudar. Um fornecedor pode alterar seu serviço. O comportamento de clientes pode se transformar. Uma vulnerabilidade de segurança pode surgir. Uma oportunidade de mercado pode aparecer. Custos operacionais podem aumentar. A estratégia da organização pode mudar. Esses fatos externos podem ser mais importantes do que o próprio ao decidir o que fazer em seguida.
Essa é uma das razões pelas quais planos de produto fixos e de longo prazo se tornam frágeis. Mesmo que o time execute perfeitamente, o ambiente pode invalidar a prioridade de ontem. A cria uma oportunidade recorrente de comparar o com a realidade mais recente.
O não deve chegar à esperando apenas confirmação. Product Ownership profissional exige disposição para mudar de direção quando as evidências mudam. O é emergente justamente porque o futuro não é totalmente previsível.
Stakeholders frequentemente são a fonte de informações sobre o ambiente. Vendas pode conhecer movimentos de concorrentes. Suporte pode identificar um novo problema do cliente. Jurídico pode saber de uma regulamentação futura. Operações pode perceber um risco de capacidade. A participação dessas pessoas transforma a Review em uma sessão de inteligência de produto.
Progresso em direção ao
A inclui a discussão do progresso em direção ao . Isso conecta o resultado imediato da ao objetivo de produto de longo prazo.
Sem essa conexão, times podem concluir boas Sprints que não se acumulam em um progresso de produto significativo. Cada pode entregar funcionalidades isoladas enquanto o permanece vago ou inalterado.
O oferece uma perspectiva estratégica. Esta aproximou o produto do estado futuro desejado? O aprendizado mostrou que o objetivo continua valioso? O objetivo precisa ser alcançado, abandonado ou perseguido de outra forma?
Por isso, a Review deve evitar concentrar-se somente no que foi concluído durante a . O grupo também deve discutir o que o resultado significa para a trajetória mais longa do produto.
Essa discussão favorece uma melhor ordenação do . Itens que antes pareciam importantes podem perder prioridade se o progresso em direção ao revelar uma restrição ou oportunidade diferente.
O que acontece com o ?
O pode ser ajustado para aproveitar novas oportunidades descobertas durante a . A palavra "pode" é importante: o não exige uma alteração visível durante toda Review, mas a adaptação deve ocorrer quando as evidências a justificarem.
Possíveis mudanças incluem adicionar novos items, remover itens obsoletos, alterar a ordenação, refinar itens existentes, revisar hipóteses ou criar experimentos para reduzir a incerteza.
O permanece accountable por essas decisões. A fornece evidências e colaboração; ela não transfere a ownership do para o grupo de stakeholders.
O deve emergir do melhor conhecimento atual sobre o produto. Se uma Review produz evidências novas e relevantes e o backlog permanece intocado apenas porque "o roadmap já foi aprovado", o foi enfraquecido.
Uma Review forte também pode reduzir o tamanho do backlog. O aprendizado frequentemente mostra que parte do trabalho planejado já não precisa ser construída. Remover trabalho de baixo valor é uma adaptação valiosa, mesmo sem adicionar uma nova funcionalidade.
Uma saudável pode eliminar trabalho
Adaptação não significa apenas adicionar solicitações. Novas evidências podem mostrar que alguns items já não valem a pena.
Valor e a pergunta "O que devemos fazer em seguida?"
O destino prático da é uma decisão seguinte melhor. Os participantes colaboram sobre o que fazer em seguida com base no resultado da e nas mudanças do ambiente.
Isso não significa planejar a próxima em detalhes. Esse é o propósito da . A melhora as informações de produto que serão utilizadas no planejamento futuro.
As perguntas podem incluir: qual problema do cliente é agora o mais importante? O mais recente gerou o valor esperado? Qual risco deve ser reduzido em seguida? O ficou mais fácil ou mais difícil de alcançar? Uma nova oportunidade é mais valiosa do que o trabalho planejado atualmente? Qual experimento poderia reduzir a incerteza?
O valor deve orientar a conversa. Times que se concentram apenas em output podem perguntar: "Qual funcionalidade vamos mostrar depois?" Times orientados a produto perguntam: "O que devemos aprender ou mudar em seguida para aumentar o valor?"
A Review pode, portanto, influenciar a estratégia, e não apenas detalhes do backlog. Uma sequência de resultados de Sprints pode mostrar que uma hipótese de mercado é fraca o suficiente para ser abandonada ou forte o suficiente para justificar mais investimento.
A é uma sessão de trabalho
O Scrum Guide descreve explicitamente a como uma sessão de trabalho e afirma que o deve evitar limitá-la a uma apresentação.
Uma sessão de trabalho contém interação. Stakeholders podem usar o produto, fazer perguntas, comparar evidências, discutir trade-offs, inspecionar o progresso em direção ao e propor opções futuras. A agenda deve favorecer colaboração real, e não acabamento teatral.
Isso não proíbe apresentações. Uma apresentação curta pode oferecer contexto. Também não proíbe demonstrações. Mostrar o pode ser muito útil. O problema surge quando a apresentação ou a demonstração se torna o evento inteiro.
Um princípio útil de desenho do evento é minimizar o tempo passivo. Se stakeholders passam noventa por cento da Review assistindo a slides e apenas dez por cento discutindo o que fazer em seguida, o equilíbrio provavelmente está inadequado.
O e o podem ajudar a criar um formato que estimule a contribuição. O formato adequado depende do produto: uso prático do produto, dashboards ao vivo, resultados de experimentos, gravações de clientes, evidências operacionais, dados de mercado ou discussão estruturada podem ser úteis.
vs. apresentação, demo, reunião de aprovação e release gate
Interpretação equivocada
O que normalmente significa
Como a é diferente
Apresentação
Comunicação unilateral em que o explica o que aconteceu.
Uma Review é colaborativa e deve levar à inspeção e a adaptações futuras.
Demo
Exibição da funcionalidade do produto ou de um concluído.
Uma demo pode fazer parte da Review, mas a Review é mais ampla: resultado do produto, ambiente, , feedback e próximos passos.
Reunião de aprovação
Stakeholders ou aceitam/rejeitam o trabalho concluído.
Done é determinado pela , e não por aprovação durante a .
Release gate
O valor não pode ser liberado até que a Review aconteça.
Um Done pode ser entregue antes do fim da ; a Review nunca é uma etapa obrigatória para liberar valor.
Por que a não é um release gate
O Scrum Guide é explícito ao afirmar que um pode ser entregue aos stakeholders antes do fim da e que a nunca deve ser considerada uma etapa de aprovação para liberar valor.
Isso importa porque o se torna real quando o trabalho atende à , e não quando o calendário chega à . Se a organização puder entregar valor com segurança antes, o não exige que espere.
Tratar a Review como um release gate cria comportamento em lote. Times retêm valor concluído, stakeholders recebem feedback mais tarde e o evento se transforma em um ponto de aprovação. Isso enfraquece os ciclos curtos de feedback que o foi criado para proporcionar.
Um produto pode ainda ter restrições legítimas de liberação, como regulamentação, coordenação de marketing ou timing operacional. Essas restrições pertencem ao contexto do produto, e não a uma exigência do de aprovação na Review.
A pode inspecionar resultados de Increments que já foram liberados. Em muitos casos, o uso em produção torna a Review mais forte, pois stakeholders discutem o comportamento real dos usuários em vez de respostas hipotéticas.
Fato importante para a prova
Um Done pode ser entregue antes da . A não é uma etapa obrigatória para liberar valor.
Por que a não é uma reunião de aceitação
Outro antipadrão comum é pedir ao que aceite ou rejeite formalmente o trabalho dos durante a . O não define esse mecanismo de aprovação.
A determina se o trabalho faz parte do . Se um não atende à , ele não pode sequer ser apresentado na como parte do e retorna ao para consideração futura.
O pode certamente decidir que trabalho adicional é valioso depois de observar o . Um stakeholder pode identificar uma necessidade ausente. O pode mudar. Mas isso é adaptação do produto, e não aprovação retroativa de que o trabalho estava Done.
Essa distinção protege o profissionalismo dos e a transparência. A qualidade não é determinada pela assinatura de um manager ou do . Os são accountable por criar trabalho que esteja em conformidade com a .
Isso também muda o comportamento dos stakeholders. Em vez de perguntar "Eu aprovo esta funcionalidade?", eles podem perguntar "O que este resultado nos ensina e o que devemos fazer em seguida?"
Participantes durante a
Participante
Contribuição principal
Apresenta e inspeciona resultados, discute o progresso em direção ao , compartilha evidências e colabora com stakeholders sobre adaptações futuras.
Traz o contexto de valor do produto e a transparência do e usa evidências de stakeholders e do produto para orientar a ordenação e decisões futuras.
Tornam o e as evidências técnicas/de produto transparentes, respondem a perguntas e contribuem com conhecimento de entrega para as opções futuras.
Garante que o evento aconteça, seja positivo e produtivo, respeite o e favoreça uma colaboração eficaz com stakeholders.
Principais stakeholders
Inspecionam resultados, contribuem com informações sobre o ambiente e feedback e colaboram sobre o que fazer em seguida.
: máximo de quatro horas para uma de um mês
A é o penúltimo evento da e possui um máximo de quatro horas para uma de um mês. Para Sprints mais curtas, o evento normalmente é mais curto.
Como ocorre com outros timeboxes do , quatro horas é um máximo, e não uma meta. Um time maduro, com os stakeholders adequados e evidências bem selecionadas, pode cumprir o propósito em menos tempo.
O não define uma fórmula proporcional. Uma de duas semanas não exige automaticamente uma Review de duas horas, embora isso possa ser razoável em determinado contexto.
A qualidade do importa mais do que a duração da reunião. Uma apresentação de trinta minutos sem colaboração não é superior a uma sessão de trabalho de noventa minutos que gera adaptações de produto importantes.
O evento deve durar o suficiente para permitir inspeção e colaboração significativas, evitando relatórios desnecessários ou preparação teatral.
Boas Reviews e Reviews fracas
Padrão
Como se apresenta
Boa
Stakeholders interagem com o ou com evidências do produto e contribuem com feedback significativo.
Boa
O progresso em direção ao é discutido explicitamente.
Boa
São consideradas mudanças de mercado, clientes, operações, regulamentação ou tecnologia.
Boa
O grupo colabora sobre opções futuras em vez de apenas ouvir.
Boa
O é adaptado quando as evidências justificam a mudança.
Boa
Resultados já liberados e dados de uso real são discutidos quando disponíveis.
Fraca
ensaiam uma demo polida de funcionalidades enquanto stakeholders permanecem passivos.
Fraca
O aceita ou rejeita cada .
Fraca
Stakeholders julgam se o time concluiu o escopo prometido.
Fraca
Ninguém discute o que mudou no ambiente.
Fraca
A reunião termina sem considerar adaptações futuras.
Fraca
Nada pode ser liberado até a conclusão da Review.
Exemplo prático - de um produto de crédito digital
Imagine um responsável por um produto de crédito digital. O é permitir que clientes elegíveis recebam e aceitem uma oferta de empréstimo responsável de forma digital e com o mínimo de atrito.
Durante a , os criam um Done que introduz um novo fluxo de verificação de renda para clientes assalariados. O time já havia liberado a mudança para um pequeno grupo em produção antes da , porque o atendia à e a estratégia de liberação permitia um rollout controlado.
Na , o não começa com uma lista de tickets concluídos. Em vez disso, o apresenta o resultado do produto e evidências. O tempo de verificação diminuiu, mas o abandono melhorou menos do que o esperado. O suporte relata que clientes estão confusos com uma mensagem de consentimento. Stakeholders de risco revelam que falsos desencontros de dados são ligeiramente maiores para uma categoria de empregadores.
Os demonstram brevemente o fluxo real porque observar a interação ajuda os stakeholders a compreender o problema. A demo apoia a inspeção; ela não é o objetivo final do evento.
Um stakeholder de marketing compartilha uma nova oportunidade de mercado relacionada a ofertas pré-aprovadas. O compara essa oportunidade com o atual. Operações explica que o tratamento manual de divergências está se tornando um gargalo. O grupo discute qual problema representa a maior restrição atual ao valor.
A conversa muda a compreensão do . Expandir a funcionalidade para clientes autônomos já não é o próximo passo óbvio. Em vez disso, o é reordenado para que o diagnóstico de divergências e a clareza do consentimento ganhem prioridade. Um pequeno experimento é adicionado para testar se uma mensagem de consentimento mais simples aumenta a conclusão do fluxo.
Ninguém aceita formalmente o . Ele já estava Done porque atendia à . Ninguém aprova a liberação; parte do valor já estava em produção. A melhora decisões futuras ao combinar evidências de produto com o conhecimento dos stakeholders.
A Review termina com uma compreensão mais clara do progresso em direção ao e uma melhor ordenação do . A da próxima utilizará essas informações atualizadas, mas a própria Review não tenta criar o plano completo da próxima .
Armadilhas comuns da sobre a
Armadilha
Interpretação correta no
A é uma demo.
Falso. Uma demo pode estar incluída, mas o evento é uma sessão de trabalho para inspecionar resultados e determinar adaptações futuras.
O aceita o trabalho concluído na .
Falso. A determina se o trabalho está Done.
Stakeholders aprovam o .
Falso. Stakeholders inspecionam, fornecem feedback e colaboram; o não define uma etapa de aprovação.
O não pode ser liberado antes da .
Falso. Um Done pode ser entregue antes.
Somente PBIs concluídos são discutidos.
Restrito demais. O grupo também discute progresso em direção ao , mudanças no ambiente, feedback e o que fazer em seguida.
A é apenas para o .
Falso. Os principais stakeholders participam.
O deve sempre ser alterado durante a Review.
Falso. Ele pode ser ajustado quando evidências ou oportunidades justificarem adaptação.
A Review planeja a próxima em detalhes.
Falso. Ela informa decisões futuras; a cria o plano da próxima .
O apresenta os resultados.
Falso. O apresenta os resultados; o ajuda a garantir um evento eficaz.
Uma de quatro horas é obrigatória.
Falso. Quatro horas é o máximo para uma de um mês; Sprints mais curtas normalmente têm Reviews mais curtas.
Uma Review bem-sucedida é aquela em que stakeholders gostam do .
Falso. Feedback difícil pode ser muito valioso se melhorar decisões.
Decisões de release pertencem à .
Falso. A liberação pode ocorrer sempre que houver um Done utilizável e o contexto do produto permitir.
Um framework de raciocínio para questões de na
Propósito: a resposta inspeciona os resultados da e determina adaptações futuras?
Stakeholders: os principais stakeholders são colaboradores ativos, e não membros passivos da plateia?
: a conversa inspeciona o progresso em direção ao objetivo de produto de longo prazo?
Ambiente: são consideradas mudanças em clientes, mercado, tecnologia, regulamentação, operações ou estratégia?
: ele pode ser adaptado com base em novas evidências e oportunidades?
Valor: a discussão está centrada no significado do resultado, e não apenas na quantidade de trabalho concluído?
Sessão de trabalho: a resposta estimula colaboração, em vez de limitar o evento a uma apresentação?
: Done é determinado antes da Review pelo padrão de qualidade, e não por aceitação durante o evento?
Release: a resposta permite que um Done seja liberado antes da Review?
: a Review respeita o máximo de quatro horas para uma de um mês sem inventar fórmulas rígidas?
Heurística rápida para a prova
Se a se parece com um palco, um comitê de aprovação ou um checkpoint de release, desconfie. Se ela se parece com + stakeholders inspecionando a realidade do produto e alterando decisões futuras, provavelmente está mais próxima do .
Conclusão: a transforma evidências do produto em decisões melhores
A é um dos eventos empíricos mais poderosos do porque reúne o produto, o , os stakeholders e as informações mais recentes sobre o ambiente antes do próximo ciclo de planejamento.
Seu propósito não é celebrar output. É inspecionar o resultado da e determinar adaptações futuras. Um Done torna o progresso visível. Stakeholders contribuem com feedback e conhecimento externo. O fornece contexto estratégico. O oferece ao um lugar para expressar aquilo que será aprendido em seguida.
É por isso que o evento precisa permanecer colaborativo. Uma apresentação pode comunicar informações e uma demo pode tornar o tangível, mas nenhuma das duas cria adaptação automaticamente. A Review tem sucesso quando as pessoas envolvidas passam a compreender algo importante melhor do que antes e essa compreensão influencia decisões futuras de produto.
O evento não é uma reunião de aprovação porque a determina se o trabalho faz parte do . Não é um release gate porque valor Done pode ser entregue antes do fim da . Não é o local em que a próxima é planejada em detalhes, pois essa função pertence à .
As melhores Reviews também olham além do . Elas inspecionam movimentos de mercado, comportamento dos clientes, operações, regulamentação, tecnologia e estratégia. Produtos complexos existem em ambientes mutáveis; portanto, o planejamento do produto precisa continuar responsivo a essas mudanças.
Na minha avaliação, a melhor pergunta para uma não é "Vocês estão satisfeitos com o que construímos?", mas sim: "Diante do que sabemos agora, qual é a coisa mais valiosa a fazer em seguida?" Essa pergunta sintetiza a mentalidade de produto do , o e o raciocínio que um candidato à deve levar para a prova.
Principais aprendizados
O propósito da é inspecionar o resultado da e determinar adaptações futuras.
O apresenta resultados aos principais stakeholders e discute o progresso em direção ao .
O e os stakeholders revisam o que foi realizado e o que mudou no ambiente.
Stakeholders são colaboradores, não apenas uma plateia.
O feedback deve melhorar a compreensão sobre valor, risco, oportunidade e direção futura.
O pode ser ajustado para aproveitar novas oportunidades.
O permanece accountable pelo .
A é uma sessão de trabalho e não deve ser limitada a uma apresentação.
Uma demo pode fazer parte da , mas a é muito mais ampla do que uma demo.
A determina se o trabalho está Done; a não é uma reunião de aceitação.
Um Done pode ser entregue antes da ; o evento nunca é um release gate.
A é o penúltimo evento da .
Ela possui máximo de quatro horas para uma de um mês; Sprints mais curtas normalmente têm Reviews mais curtas.
A informa o que acontece em seguida, mas a cria o plano detalhado da próxima .
Questões da frequentemente testam equívocos relacionados a demo, aprovação, status e release gate.
