Sprint Review: Como funciona uma Review no Scrum & Agile?
A atividade mais óbvia em uma Sprint Review é a demonstração da funcionalidade construída no Sprint anterior. No entanto, uma boa Sprint Review é mais do que apenas uma demonstração. Vamos analisar juntos uma agenda para uma reunião de Review.
Criar as condições certas para a Review
O Product Owner inicia a Sprint Review Meeting dando as boas-vindas a todos os participantes. É totalmente suficiente dizer algo como: "Obrigado por estarem todos aqui."
Se os presentes não se conhecem entre si, o Product Owner pode pedir que se apresentem brevemente. No início de uma nova iniciativa de desenvolvimento de produto, uma rodada de apresentações é sempre uma boa ideia. O Product Owner sabe que o Joe do Marketing é o Joe do Marketing; mas os membros da equipe talvez não saibam.
Além disso, faz sentido que todos os participantes se apresentem brevemente quando novos participantes ocasionalmente se juntam às Sprint Reviews. Pode ser que o Joe do Marketing só venha às Sprint Reviews dos dois Sprints em que a equipe trabalhou em features relacionadas ao marketing.
A apresentação deve ser realmente curta e objetiva. "Oi, sou o Mike e sou desenvolvedor. Trabalhei nas features do carrinho de compras" já é quase demais. "Oi, sou o Mike e sou desenvolvedor" seria suficiente na maioria dos casos. No entanto, quando uma equipe atinge um certo tamanho, pode ser útil para os stakeholders saber brevemente no que cada pessoa trabalhou.
Após as boas-vindas e a rodada de apresentações, se necessária, o Product Owner pode estabelecer algumas regras ou anunciar as expectativas para a Sprint Review. Por exemplo, alguns Product Owners acham importante ressaltar que devemos sempre manter a cordialidade na Sprint Review. Se alguém não gostar de como uma feature foi implementada, pode dizer isso sem problemas; mas não deve chamar a implementação de "idiota". Sim, claro que todos já sabemos essas coisas, mas às vezes precisamos ser lembrados.
Dependendo do número de participantes e de muitos outros fatores, o Product Owner também pode explicar aos presentes que na Review busca-se feedback sobre as features construídas até o momento, mas que este não é o momento nem o lugar para redesenhar features completamente.
Assim que terminar a introdução e as regras da Review, é hora de passar para o próximo ponto da agenda.
O que é demonstrado em uma Review - e o que não é?
Neste ponto, muitas equipes começam diretamente com a demonstração. Eu recomendo que o Product Owner primeiro dê uma breve visão geral sobre o que será demonstrado e o que não será.
Para evitar que o Product Owner simplesmente leia uma lista de itens que os participantes não conseguem acompanhar, isso deve ser mostrado de forma visível para todos em um monitor ou projetor. Ou pode-se imprimir a lista antecipadamente para aqueles que possam querer uma cópia.
Pessoalmente, gosto de enviar essa informação na noite anterior à reunião como documento Word por e-mail para todos os potenciais participantes do Sprint Review Meeting. Isso dá às pessoas a chance de ver antecipadamente o que será demonstrado. Com base nisso, cada um pode decidir se vale a pena participar do Sprint Review.
A tabela a seguir mostra as informações que, na minha opinião, são relevantes para cada Product Backlog Item. Eu sugeriria listar os itens na ordem em que serão demonstrados. No entanto, isso pode ser alterado espontaneamente conforme necessário.
O primeiro ponto na tabela é uma descrição do respectivo item. Lá é inserida uma User Story ou outra descrição. Em seguida vem o tamanho dos itens – geralmente em Story Points. Depois vem o status dos itens. Principalmente se trata de saber se estão concluídos ou não. Mas tudo o que parecer importante nesse sentido também pode ser adicionado ali. A última coluna indica se o respectivo item será demonstrado ou não.
Você pode estar se perguntando por que deveria haver itens na lista que não serão demonstrados. Na tabela acima, incluí alguns exemplos. Obviamente, o item que foi incluído no Sprint mas depois foi descartado não pode ser demonstrado. Além disso, listei uma correção de bug que se trata apenas de uma atualização de um caractere em uma tela – esse item também não está previsto para demonstração.
É bem possível que um ou mais participantes perguntem sobre um item que originalmente não estava previsto para a demo. Se isso acontecer, você pode apresentar esse item junto com os outros sem problemas. Não se trata de evitar que certos itens sejam mostrados, mas de respeitar o tempo das pessoas, não mostrando itens sobre os quais não se precisa de feedback.
Na tabela de exemplo, listei um Product Backlog Item que foi adicionado durante o Sprint. Considero útil poder identificar quais itens foram planejados desde o início para o Sprint e quais foram adicionados durante o Sprint. Se acontecer com frequência de itens serem adicionados durante o Sprint, pode-se pensar em adicionar uma coluna à tabela para registrar se os itens foram planejados ou adicionados posteriormente.
Além disso, pode-se inserir uma coluna bem à direita indicando se os itens foram aceitos pelos participantes da Review Meeting, se estão prontos para um Release etc. Isso é especialmente útil quando essas decisões são uma parte oficial do Sprint Review.
Tente não gastar muito tempo nesta parte da agenda. O objetivo aqui não é obter feedback sobre os itens ou falar sobre por que um item planejado foi implementado apenas parcialmente. Esta lista serve apenas para apresentar os conteúdos da reunião. Depois que o Product Owner apresentar esta lista, segue-se para a parte principal do Sprint Review: a demonstração.
Demonstrar novas funcionalidades
Este é o coração de toda reunião de Sprint Review. Se você já realiza Sprint Reviews, é bem provável que esta seja a única parte da agenda que você realmente executa.
Nesta parte do Sprint Review, você percorre gradualmente a lista de itens que mostrou anteriormente aos presentes. Lembre-se de que o objetivo principal de uma reunião de Sprint Review é obter feedback.
Não existe uma regra fixa sobre quem deve fazer a demo. Em alguns casos, o Product Owner assume essa tarefa. Eu sempre sugeriria isso quando stakeholders particularmente difíceis participam do review. Em outros casos, os próprios membros da equipe demonstram os itens em que trabalharam. Quase qualquer variação é permitida aqui. Simplesmente experimente um pouco e descubra o que funciona melhor para a sua equipe.
Discutir os pontos mais importantes
Quando todos os itens do Product Backlog concluídos foram demonstrados, são discutidos os principais eventos ou problemas deste Sprint.
A discussão pode ser moderada tanto pelo Scrum Master quanto pelo Product Owner. Na minha experiência, ambos os modelos funcionam igualmente bem. Pessoalmente, porém, tenho uma leve tendência a achar que o Scrum Master deveria assumir esta parte da reunião.
Até este ponto do Review, o Product Owner terá falado muito mais do que o Scrum Master. Por isso, considero um bom equilíbrio quando o Scrum Master modera esta parte da agenda. Além disso, falando estritamente, esta é geralmente mais uma discussão sobre o processo do que sobre o produto em si. Portanto, está um pouco mais dentro da área de atuação do Scrum Master.
Apresentar os próximos itens do Product Backlog
O último item na agenda da Sprint Review deve ser uma discussão sobre os próximos trabalhos no Product Backlog . Como o objetivo da Sprint Review é obter feedback sobre o trabalho do Sprint atual, isso frequentemente influencia também os trabalhos dos Sprints seguintes.
Se os stakeholders gostarem muito do visual das novas telas, por exemplo, o Product Owner pode querer adaptar rapidamente outras áreas do produto ao novo design. Ou então, se a forma como as features foram implementadas não agradar tanto ao stakeholder , o próximo Sprint pode ser usado para corrigir esses pontos em vez de continuar com os próximos itens (como teria acontecido sem uma Sprint Review).
O Product Owner inicia a discussão com a apresentação dos próximos itens potenciais do Product Backlog. Ele pode dizer algo como: "Na tela vocês veem dez itens que eu tinha planejado para o próximo Sprint. No entanto, eu gostaria de adicionar o item XY, que surgiu hoje. Provavelmente vou colocá-lo como item nº 3."
O Product Owner então pede a opinião dos participantes sobre essa lista. Porém, na minha opinião, o Product Owner não deveria fazer a priorização durante a Sprint Review com base nesses comentários. Há várias razões para isso. O Product Owner pode precisar de um tempo para refletir sobre o que foi dito. Ou talvez o Product Owner queira obter estimativas do time sobre as mudanças solicitadas na Review, etc. Então o Product Owner coleta opiniões na Sprint Review e toma as decisões finais com calma após a reunião.
Encerrar a Review
Encerre a reunião simplesmente agradecendo a todos pela participação. Considere também se você não gostaria de agradecer à equipe como um todo pelo trabalho no último Sprint, ou de vez em quando a um ou dois membros da equipe que demonstraram um desempenho particularmente bom. Em seguida, lembre a todos quando e onde será a próxima reunião de Sprint Review.
Após a Sprint Review
Mesmo que não faça parte diretamente da agenda da Sprint Review, deve-se garantir que todos os novos itens do Product Backlog sejam transferidos para a ferramenta do time ou escritos em um Post-It e colocados no Scrum Board.
