E aí, pessoal.
O post dessa semana é algo voltado mais para o básico, afinal de contas é sempre bom estarmos revendo nossas bases teóricas :). Vou falar sobre uma cerimônia bem importante do Scrum: a Sprint Review.
Sabe quando finaliza uma sprint e o time precisa mostrar o que foi feito? Então, a sprint review serve justamente para isso. Ela deve ocorrer sempre no final de cada sprint com o time de desenvolvimento, o Product Owner (PO), pessoas relevantes para o produto e com a devida facilitação do Scrum Master (SM). Rafael Sabbagh, em seu livro Scrum Gestão Ágil Para Projetos de Sucesso, é bem categórico ao afirmar a importância da participação de pessoas relevantes para o produto:
A presença de pessoas relevantes na reunião cria a oportunidade para valiosos feedbacks sobre o produto.
Perceba que pessoas relevantes para o produto nem sempre é o cliente. Podemos considerar aqui usuários-chaves, gerentes, entre outros.Nessa reunião, o PO vai decidir se a funcionalidade foi realmente finalizada de acordo com a Definição de Pronto – definida anteriormente no sprint planning e em conjunto com o time de desenvolvimento – e, principalmente, coletar feedback sobre o que foi feito e entregue até então. Devemos entender que os feedbacks são de extrema importância para a saúde do projeto, pois reduzem, fortemente, o risco do seu produto ser um fiasco.
Mas Diogo, aqui onde eu trabalho, nossas reviews ocorrem da seguinte forma: o time apresenta para o PO o que foi feito e ele decide se alcançamos a meta ou não. Estamos fazendo da forma errada? Então, claro que est.. não estou entrando no mérito de certo ou errado, mas entenda que nessa situação, apenas o feedback vindo do PO aumenta consideravelmente o risco do projeto, pois ele(a) pode não ser o usuário-chave do incremento do produto em questão.
O quanto antes vocês tiverem a opinião das pessoas a qual se destina, de fato, o incremento do produto, resultará no alinhamento das expectativas/objetivos caso o time de Scrum tenha seguido por um caminho errado (a nível de negócio).
No mundo ideal, essa reunião deve ocorrer com o PO apresentando o que foi feito e o time de desenvolvimento dando suporte necessário em relação a parte técnica, respondendo as dúvidas de todos os envolvidos.
Procure sempre ater-se em demonstrar o que foi feito. Qualquer coisa que não faça sentido, como slides desnecessários, desculpas, reclamações, etc, aumentam as chances das pessoas evitarem as próximas reviews. Qualquer problema que aconteceu durante a Sprint, deve ser discutida durante a retrospectiva.Sendo assim, devemos ter em mente e considerar a Sprint Review como uma reunião de inspeção e adaptação do produto. Ou seja, todo feedback obtido nessa reunião servirá de base para o PO organizar o Product Backlog no decorrer do projeto. Vale ressaltar também que, nem sempre, o que foi desenvolvido entra em produção logo de cara. Precisa-se levar em considerações as metas da release. Esse é um trabalho apenas do PO e de mais ninguém, pois é ele que cuida do produto a nível de negócio.
Antecipar feedbacks também reduz os riscos.
Espero que tenham gostado,
Grande Abraço
Achei o post super oportuno, principalmente por ele relembrar que o objetivo da review é obter o feedback dos usuários do produto e não apenas a opinião do PO. Essa visão já elimina a dúvida que sempre ocorre quando o PO é muito próximo do time e tem visibilidade quase que diária do que está acontecendo.