A Sprint Review (Revisão da Sprint) é a reunião cujo objetivo primário é receber feedback de clientes, usuários ou consumidores do serviço ou produto que o seu time está criando.
Vantagens da Sprint Review
Além de cumprir esse propósito, uma boa revisão de Sprint proporciona:
Relacionamento
Time e clientes se veem, não são estranhos e um começa a entender melhor o outro. Clientes são ouvidos e podem compreender os desafios do time.
Movimento
Os clientes sabem que o produto / serviço está sendo construído. Não fica aquela sensação de “estou sendo enrolado” ou “cadê o que eu pedi?”
Transparência
Uma Sprint Review é o momento de apresentar o produto / serviço em funcionamento, com esplendor e glória. Se a Review apresenta documentos que dizem que o andamento existiu sem apresentar o produto / serviço você não está fazendo uma Review.
Direcionamento
Como durante a construção haverá várias revisões de várias Sprints, todos sabem qual a direção que o produto está indo. Sem surpresas ao final de 6 meses ou 1 ano.
Cultura da Melhoria contínua
Outra grande vantagem da Sprint Review é que ela auxilia a disseminar a cultura de melhoria contínua. A cada Sprint o time se obriga a entregar um incremento do produto ou serviço e apresentá-lo para o cliente. A cada iteração um produto melhor, mais completo e com mais qualidade.
Quem participa da Sprint Review?
O time inteiro deve participar. Muitas das vezes tentam colocar apenas as pessoas que fazem papel de Product Owner para tal. Não é uma boa prática, pois essa pessoa vira uma espécie de “menino de recados” entre o time e o cliente.
Como tudo na vida, há exceções. Nem todo cliente será uma pessoa legal. Você passará por pessoas bem inconvenientes e, infelizmente, negar um cliente é bem difícil quando as contas estão vencendo. Logo, é possível que em algumas situações você queira proteger o time dessas pessoas. Longe do ideal, mas em alguns momentos necessário.
Agora, uma coisa é importante nessas situações. Não tente ser superprotetor do seu time. Eles não são seus filhos e mesmo que fossem você não poderia guardá-los em uma bolha. Pessoas ruins existem e profissionais devem aprender a lidar com elas.
Resumindo, participa da Sprint Review: desenvolvedores, Product Owner e Scrum Master.
A Sprint Review é para o cliente
Se na Sprint Review você apresenta para o Product Owner (PO), está errado. PO não é cliente, não é usuário do produto e não é consumidor do serviço. PO é PO. A revisão deve fazer com que o cliente experimente o produto e dê feedback. Se o feedback do PO é importante, faça isso ao longo do fluxo de construção.
Nem sempre será fácil encontrar esse cliente. Muitas das vezes você trabalha para a pessoa que te contratou, mas ela não será a utilizadora do produto ou serviço.
Lembro de certa vez que trabalhei com um time que projetava celulares para pessoas de baixa renda. Eram smartphones que custavam entre R$100,00 até R$500,00. Eles estavam desenvolvendo um aplicativo para auxiliar a locomoção de pessoas na cidade. No caso, Manaus. Infelizmente (ou felizmente) nenhuma das pessoas envolvidas na construção precisava daquele tipo de celular.
Como fazer uma Sprint Review com pessoas que não são usuárias ou potenciais usuários do serviço? Das duas uma. Ou você tem um baita expert no assunto ou você não faz. O feedback que você receberá será bem pobre, muito mais baseado no achismo do que na necessidade. Nesse caso, o que fizemos foi ir para os pontos de ônibus e moto táxi (comuns naquela capital), colocar as pessoas para utilizar e avaliar como elas utilizavam tanto o celular quanto o aplicativo.
Passamos por um caso semelhante em um cliente que produzia máquinas de pagamento de débito, crédito e Pix, porém o público-alvo eram os vendedores de rua ambulantes ou fixos. Uma Sprint Review em uma sala com iluminação, ar-condicionado e pessoas que nunca estiveram do lado do fornecedor seria irrelevante. Nesse caso fomos direto aos vendedores ambulantes nas ruas com calor de fevereiro no Rio de Janeiro. Ambiente real com cliente real é igual a feedback valioso.
Como fazer uma Sprint Review
Não existe uma forma única de fazer essa reunião. Particularmente eu prefiro utilizar a seguinte forma:
Listamos todos os itens de trabalho (Histórias de Usuário) para o cliente. Essa listagem é interessante para recordar o que fizemos de um ciclo de construção (Sprint) para o outro. Essa lista fica em um lugar visível para todos. A partir daí ele utilizará o produto / serviço como desejar.
Ele pode seguir a lista de itens de trabalho ou não. Quando ele fizer algo que não estava na lista é sempre bom perguntar o porquê. Muitas das vezes a jornada do consumidor que construímos não é a melhor para ele ou não é intuitiva.
A única intervenção que eu faço além dessa é lembrar esse cliente caso ele deixe de avaliar algum item. Fora isso, é um momento da pessoa com o produto / serviço.
Sempre anote comportamentos inesperados como idas e vindas em diferentes funcionalidades; mensagens que eram importantes, mas foram ignoradas; impaciência por lentidão; medo de informar dados pessoais etc. Tudo o que parece fora do esperado é uma possível fonte de melhoria. Além das próprias opiniões que a pessoa dará durante o uso.
Cuidados com o feedback
Após uma Sprint Review há uma tendência de colocarmos todos os feedbacks no topo do Product Backlog. Isso não precisa ser uma verdade. É trabalho do Product Owner avaliar o que é mais importante: os recém-dados feedbacks ou os itens que já estavam no backlog. Além disso, nem todo feedback precisa ir para o backlog. Alguns serão muito custosos para serem construídos e os benefícios não compensam o investimento.
Dados são muito importantes
A sua review será mais valiosa se você tiver dados reais sobre o uso do produto e serviço. Entretanto, para você ter dados, seu time deverá entregar o produto / serviço em ambiente de produção. Mesmo que a disponibilização seja apenas para um grupo de clientes ao invés da totalidade. Se uma pessoa achar que uma funcionalidade do seu produto é horrível e todos os demais clientes estão utilizando a mesma funcionalidade sem problemas, os dados poderão ser usados para decidir se a opinião do cliente que participou da Sprint Review é relevante ou não. Contra fatos não há argumentos.
Só posso entregar o incremento do produto / serviço depois da Sprint Review?
Essa eu vou deixar para o Ken Schwaber e Jeff Sutherland, criadores do Scrum responderem:
“Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor.”
(Guia do Scrum 2020, p. 13)
Simplificando, não precisa esperar o Sprint Review para realizar a entrega do incremento do produto / serviço.
Curtiu? Dá uma olhada no nosso treinamento Certified ScrumMaster® (CSM) e Certified Scrum Product Owner® CSPO
