Como fazer a sprint review com um app funcionando em vez de slides

Faça a sprint review colocando uma versão rodando do produto na frente dos stakeholders e deixando que eles usem, com os slides reduzidos a um título e uma pauta. O PO prepara um roteiro curto dentro do app, passa o mouse para outra pessoa e anota o feedback como item de backlog enquanto a reunião ainda acontece.

Por que slide atrapalha a review

Slide de funcionalidade é afirmação. Tela funcionando é prova. Quando o time mostra o print do novo checkout com uma seta e uma legenda, o público concorda com a cabeça porque não tem como discordar. A funcionalidade vai ao ar, alguém usa pela primeira vez, e a review de verdade acontece em produção, na forma de chamado no suporte.

O Scrum Guide descreve a sprint review como inspeção do incremento. Não dá para inspecionar a foto de um incremento. Só se inspeciona algo que se comporta. Além disso, o slide empurra para um formato de palestra: o time fala, os stakeholders escutam e os mais quietos continuam quietos. Com o software aberto o formato vira. As pessoas se inclinam, perguntam se podem testar, e a conversa gira em torno do produto, não da apresentação.

Tem também o lado prático. Montar apresentação consome tempo que poderia ir para o produto. Já vi time gastar a tarde da véspera caprichando em slide de coisa que já estava pronta.

Preparando uma demo que dá para clicar

O objetivo é que o stakeholder abra um link e faça a tarefa sozinho. Para isso você precisa de um ambiente que não seja o seu notebook, nem a branch de um dev, nem a produção com dados reais de cliente. Um ambiente de homologação estável, com dados verossímeis, resolve.

Dois dias antes da review, o PO faz um ensaio. Abra o app como um usuário novo: faça login, percorra cada história concluída na sprint e anote o que quebra, confunde ou precisa de explicação. Se você precisa explicar, o stakeholder vai precisar da mesma explicação depois, quando você não estiver por perto. Corrija ou anote.

Depois escolha o roteiro. Não demonstre ticket por ticket na ordem em que aparecem no quadro. Agrupe o que ficou pronto pelo objetivo do usuário: cadastrar, encontrar um pedido, pagar, receber o comprovante. Cada grupo vira um trecho curto da demo, no máximo cinco minutos. Trabalho sem superfície visível, como ganho de performance, merece uma frase, não um bloco.

Se parte da sprint não terminou, mostre assim mesmo, bem identificada. Meio fluxo funcionando com a etiqueta ainda não concluído diz mais para a sala do que uma história escondida. Só não conte como entregue.

O que mostrar e em que ordem

• Comece pela meta da sprint em uma frase e diga se foi atingida. Fale a verdade, inclusive quando a resposta for em parte.
• Mostre primeiro o fluxo principal de ponta a ponta, como o usuário faria, antes de qualquer detalhe.
• Depois mostre as partes novas dentro desse fluxo, não como telas soltas.
• Inclua um caso de borda de propósito, como lista vazia ou senha errada, para que vejam que foi pensado.
• Termine com o que não ficou pronto e o que o time aprendeu, em dois minutos.

A demonstração deve ocupar menos da metade da reunião. O resto é para o pessoal usar e opinar. Numa review de uma hora, mire em vinte minutos seus e o restante com eles no comando.

Coletando feedback enquanto eles clicam

Terminada a parte guiada, mande o link no chat e peça para dois ou três stakeholders executarem uma tarefa específica. Não peça para explorar, porque explorar rende elogio. Dê uma tarefa: cadastrar um cliente e emitir uma cobrança. Observe onde hesitam. Quem passa cinco segundos com o mouse parado sem clicar entrega mais informação do que qualquer comentário feito depois.

Escolha uma pessoa do time como escriba, e que não seja o PO, que está ocupado falando. O escriba registra cada reação num documento compartilhado com três campos: o que aconteceu, quem falou e em que tela. Sempre que der, escreva a fala da pessoa. Achei confuso não serve para nada depois. Não entendi que Arquivar só esconde o projeto, não apaga é algo em que um dev consegue trabalhar.

Faça perguntas melhores que gostou? O que você faria agora aqui? O que esperava que acontecesse ao clicar nisso? O que falta para você usar isso na segunda-feira? A última é minha favorita, porque separa necessidade real de gosto pessoal.

Um exemplo prático

Um time constrói um sistema de agendamento para uma rede pequena de estúdios de pilates. Nesta sprint terminaram o cancelamento de aula pelo aluno e a lista de espera. Em vez de slides, a PO compartilha o link de um ambiente de homologação com alunos fictícios. Ela gasta dez minutos no roteiro: a aluna entra, cancela uma aula e a próxima da lista de espera é promovida.

Depois pede que a gerente do estúdio, que participa como stakeholder, cancele uma aula por conta própria. A gerente clica em Cancelar e o app confirma. Ela franze a testa e pergunta: espera, e se for menos de duas horas antes da aula? Nesse caso a gente cobra. Ninguém tinha falado de regra de cancelamento tardio. O escriba anota a frase literal, com a tela onde aconteceu.

Outra stakeholder, que cuida da recepção, testa a lista de espera e pergunta por que não consegue ver quem está esperando. É o segundo item. O terceiro vem de um desenvolvedor da sala, que percebe que duas alunas promovidas ao mesmo tempo ficariam com a mesma vaga. Um bug de verdade, achado na reunião e não numa manhã de sábado às dez horas.

Se você usa uma ferramenta como o StarBuild para gerar o app, ainda ganha um preview publicado que não depende da máquina de ninguém. É esse tipo de ambiente que torna possível o momento de passar o mouse para o stakeholder.

Transformando feedback em backlog

Em até um dia, separe as anotações do escriba em quatro grupos. Bugs vão direto para o backlog com passos para reproduzir. Regras ou necessidades que faltavam, como a taxa de cancelamento tardio, viram novas histórias com usuário e resultado claros. Preferências, como mudar a cor, vão para uma lista de estacionamento que você revisa no refinamento, não agora. E dúvidas que você não sabe responder viram spike ou tarefa de investigação para o PO.

Escreva cada história com as palavras da pessoa. O item do cancelamento tardio poderia ficar assim: como gerente do estúdio, quero que cancelamentos com menos de duas horas de antecedência sejam marcados como tardios, para poder cobrar o aluno. Os critérios de aceite entram depois, não na reunião. Durante a reunião você só captura.

Feche o ciclo. Mande aos stakeholders uma lista curta do que saiu da review e onde cada item foi parar. As pessoas dão feedback melhor na review seguinte quando enxergam que a anterior mudou alguma coisa. Se decidir não fazer um item, diga isso e explique o motivo em uma frase. Gera mais confiança do que silêncio.

Onde isso costuma dar errado

A demo cai ao vivo. Previna com o ensaio e um plano B: uma gravação curta do caminho feliz para tocar se o ambiente falhar. O stakeholder que sequestra a reunião com um pedido de redesenho: estacione com educação, anote e siga. O time que só mostra caminho feliz: mostre um estado de erro de propósito. E a review que vira reunião de status, sem ninguém encostar no produto. Se ninguém clicou em nada, não foi review.

Se ninguém na sala tocou no produto, foi apresentação, não review.

Experimente uma vez numa sprint pequena. Corte os slides, mande um link e conte quantas surpresas aparecem nos primeiros vinte minutos.