Template para a Review

Desde que iniciei como Scrum Master, sempre me preocupei com o quanto cada cerimônia estava sendo efetiva e, caso não fosse, qual seria a razão. Avaliando as Reviews, sabia que estávamos tendo dificuldade para demonstrar as entregas para quem não participava do dia a dia do time e sabia que poderia melhorar a minha facilitação para resolver esse problema.

Na época, estava em um time que contava com o apoio de dois Agile Coaches e aproveitei para pedir uma opinião sobre como melhorar esse momento. Depois de participarem de uma Review do time, eles me sugeriram usar uma apresentação de slides para guiar os stakeholders pelas entregas. E é isso que quero compartilhar neste post de hoje.

Propósito da Review

Primeiro, vamos relembrar o propósito da Review:

O propósito da Review é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Time Scrum apresenta o resultado do trabalho desempenhado para os stakeholders chave e o progresso em direção ao Objetivo do Produto é discutido.

Pensando nesse propósito, podemos dividir a apresentação de slides para que, ao mesmo tempo que mostra os resultados, deixa claro qual foi o acordo do time na Sprint para atingir o Objetivo do Produto.

Estrutura da apresentação de slides

Objetivo da Sprint

Ao final da Planning, sempre definimos com o time qual é o Objetivo da Sprint. Por mais que as primeiras definições pareçam meio que um “copia e cola” dos títulos dos itens do Sprint Backlog, eu gosto de fazer esse exercício de ter objetivos cada vez mais sucintos e que englobam toda a nossa entrega de valor.

Essas características do objetivo são importantes principalmente na Review, quando queremos mostrar para pessoas que não participam do nosso dia a dia o que pretendíamos entregar de valor para o usuário. Abrir a apresentação com um objetivo vago ou com termos desconhecidos para o público sempre gera algum tipo de dúvida ou discussão. E é também por isso que gosto de abrir a cerimônia com o nosso objetivo, porque nos ajuda a refinar essa definição.

Demonstrações

Depois de deixar claro qual era o nosso objetivo, tudo o que for possível demonstrar é exibido para os stakeholders. Para organizar essa parte, geralmente combino com o time um horário limite para o envio das demonstrações, que podem ser de dois tipos:

1. Vídeos ou fotos
2. Demonstrações ao vivo

No primeiro caso, incluo o material na apresentação e quem for demonstrar se guia pelos slides. No segundo caso, incluo uma marcação nos slides para dar a deixa para quem precisa compartilhar a tela fazer a sua demonstração.

Gosto de organizar dessa forma para que não pareça que não estamos coordenados ou que não nos preparamos para a apresentação. Problemas podem acontecer, mas o combinado evita que aconteçam sempre.

Entregáveis do Product Backlog

Nem todos os itens do Sprint Backlog podem ser demonstrados, então é importante listar quais foram os entregáveis da Sprint. Nessa lista, incluo o título de cada um dos itens que foram desenvolvidos, com o tipo indicado. Por exemplo:

• [História] Recuperação de senha
• [Tarefa] Ideação da tela de listagem de usuários
• [Bug] Login social não está funcionando

Todos os itens são listados, mesmo aqueles que foram demonstrados nos slides anteriores.

Transbordo do Product Backlog

É normal que as Sprints finalizem sem entregar 100% do que foi planejado. Quando isso acontece, incluo um slide com a listagem semelhante à dos entregáveis, só que aqui podemos fazer algumas observações para dar visibilidade.

Por exemplo, se um item foi incluído após a Planning (não vamos fingir que não acontece), deixo uma marcação sinalizando que é um item extra. O que não seria necessariamente um transbordo. Para os itens que estavam no Sprint Backlog, geralmente sinalizamos o estado e/ou uma justificativa para estar transbordando para a próxima Sprint:

• Item não foi iniciado
• Item foi iniciado, mas encontramos um impedimento
• Item já foi desenvolvido, mas ainda não foi testado
• Item foi iniciado e não deu tempo de finalizar por um erro na estimativa
• Qualquer outra justificativa que dê visibilidade do trabalho que está sendo desempenhado pelo time

Problemas em relação ao transbordo devem ser resolvidos internamente com o time, para evitar que se repitam pelos mesmos motivos. Mas é importante dar visibilidade das situações que o time está enfrentando e mostrar que erros acontecem, só nos resta resolver.

Pontos de atenção

Se houveram impedimentos, novas informações, mudanças nos padrões de desenvolvimento ou qualquer evento que impactou o trabalho do time, eles são listados nesse slide.

Assim como no slide anterior, a intenção é dar visibilidade do que foi enfrentado pelo time durante a Sprint para chegar no trabalho que está sendo apresentado. Também é um bom momento para sinalizar aos stakeholders qualquer apoio que seja necessário. Seja algum direcionamento ou até mesmo notificar descobertas que podem impactar o trabalho.

Idealmente, apoio aos stakeholders deve ser solicitado assim que identificado durante a Sprint, mas dependendo do momento da descoberta, alguns itens podem ficar para a Review.

Feedback

Geralmente, todos os comentários são feitos durante a reunião. Mas isso costuma acontecer com times que estão acostumados a trabalhar juntos há algum tempo. Por isso, gosto de deixar um slide no final com o convite para que os presentes deem os seus feedbacks sobre a entrega.

Esse é o momento de entender se estamos no caminho certo, se os stakeholders reconhecem no nosso trabalho os direcionamentos do produto e se ficou alguma dúvida na apresentação. Considero muito importante que sempre existam comentários durante a Review, principalmente para mostrar ao time que o trabalho desempenhado está sendo acompanhado e que o nosso trabalho faz sentido dentro da organização.

Referências

Todas as informações que uso para montar a apresentação ficam registradas na ferramenta de gestão (atualmente estamos utilizando o Jira) e nos documentos compartilhados (usamos o Coda). Para que os interessados possam consultar as informações mais completas, além do resumo da apresentação, deixo os links com as fontes listadas no slide final.

Além disso, incluo na documentação do time a apresentação de slides da própria Review.

Template de exemplo

Criei esse template para exemplificar o formato que uso. Ele tem toda a estrutura que descrevi no post e costumo usar ela como ponto de partida para as primeiras Reviews. Conforme vou trabalhando junto do time e entendendo alguns pontos específicos das entregas, vou evoluindo para que reflita as informações que os stakeholders mais solicitam ou estão acostumados a receber e não estão contempladas nesse modelo inicial.

Depois que comecei a usar a apresentação de slides, sinto que a cerimônia ficou muito mais organizada e muito mais esclarecedora para os stakeholders. Combinar com o time a apresentação e o que vai ser demonstrado também ajuda todos a entenderem o que conseguiram avançar na última Sprint e muitas vezes até nos surpreendemos ao ver quanta coisa foi feita.

Espero que essa dica te ajude a melhorar as Reviews do teu time.

Até a próxima!

Copiar link