O Product Owner e as Reuniões SCRUM

Mais que um modismo, a agilidade é uma realidade. Praticamente, quase a totalidade das organizações possuem Projetos Ágeis que utilizam SCRUM. De acordo com o Relatório de Tendências SCRUM.org, 81% dos entrevistados adotaram o Framework SCRUM com outras práticas agile, por exemplo Kanban, DevOps ou XP.

O que é o SCRUM?

O Scrum é um Framework de desenvolvimento de projetos com Abordagem Ágil. A principal finalidade é entregar valor ao cliente em tempo menor, com base em que um produto ou serviço não precisa estar totalmente concluído para ser disponibilizado ao cliente. A ideia é possibilitar a utilização das soluções e incrementá-las conforme surgem outras necessidades. Ou seja, fornecendo sempre um Mínimo Produto Viável, ou MVP, funcional, com funcionalidades ou características que agreguem valor para o cliente.

O SCRUM surgiu com base no Manifesto Ágil, que é um conjunto de princípios e valores que valorizam a entrega mais rápida de produtos ou serviços aos clientes.

Originalmente, o SCRUM e a Abordagem Ágil surgiram com o intuito de facilitar, agilizar e potencializar a assertividade dos projetos de desenvolvimento de software. Contudo, nos dias atuais, as organizações adotam o Framework SCRUM em todos os segmentos de mercado.

O funcionamento do Framework SCRUM

No SCRUM é imperativo que as equipes sejam auto-gerenciáveis e multidisciplinares. O que isso quer dizer? Não existe a figura do Gerente, no topo da pirâmide, tomando conta do que as pessoas estão fazendo. Essa é uma Abordagem Tradicional. O Scrum, por outro lado, conta apenas com três papéis principais: o Scrum Master, o Product Owner e o Time de Desenvolvimento.

O time de desenvolvimento é composto por profissionais que irão produzir o Produto ou Serviço propriamente dito.  Imperativo que ele seja multidisciplinar e possuir todas as competências necessárias para a realização do projeto.

O Scrum Master é o profissional encarregado pelo processo em si. Ele não gerencia ninguém! Ele é um líder servidor, um maestro, que conduz toda equipe pelas reuniões, auxilia na produção dos artefatos do Scrum (Product Backlog, Sprint Backlog e Incrementos), facilita a remoção de impedimentos que possam impactar negativamente o andamento do trabalho e realiza ajustes e mudanças que possam ser necessários para que o SCRUM seja executado conforme as melhores práticas.

Por fim, eis o Product Owner, o profissional responsável pela visão do produto. Ele é um membro indispensável de qualquer equipe ágil SCRUM. O objetivo principal no papel de um Product Owner é representar o cliente para a equipe de desenvolvimento. Uma atividade principal é gerenciar e tornar visível o Backlog do Produto ou a lista priorizada de requisitos para o desenvolvimento futuro do produto ou serviço.

Atuação do PO nas Reuniões SCRUM

É fortemente recomendável a presença dos PO em todas as reuniões SCRUM (ou cerimônias) possíveis. Mas, por que? Quanto mais presente e atuante o PO no projeto, menos chances de problemas teremos.

Comecemos pela Sprint Planning. É imperativo a presença e participação ativa do PO. Durante esta cerimônia, o PO descreverá os ítens de maior prioridade para a equipe. A equipe vai fazer várias perguntas para que possam transformar uma história de usuário de alto nível do Backlog do Produto em atividades mais detalhadas do Sprint Backlog. É fortemente recomendado que o PO compareça à reunião de Sprint Planning preparado para falar acerca de ao menos três itens do backlog do produto que poderão ser contemplados no Sprint. Vamos imaginar que a equipe sempre conclua três itens priorizados no Product Backlog. Então, neste caso hipotético, a sugestão é sempre que o PO compareça na reunião preparado para falar sobre as seis principais prioridades da lista no momento.

A próxima é a Daily. Uma reunião stand up de no máximo 15 minutinhos. Embora o PO não interaja na reunião, se estiver presente como ouvinte ele toma ciência de impedimentos, e anota o que está impactando o processo. Terminou a reunião, já vai logo resolver os impedimentos com as pessoas do time DEV.

Em seguida temos a Sprint Review, ou simplesmente, a apresentação do que foi feito na Sprint. Novamente, é imperativo a presença e participação ativa do PO. O fundamental objetivo da Sprint Review é a validação das entregas da equipe e verificação dos critérios estabelecidos no planejamento foram executados com eficácia. É a hora de coletarmos os feedbacks do que foi produzido pela equipe. Trocando em miúdos, é um bate papo entre a equipe e as partes interessadas acerca de como podemos melhorar o produto ou o serviço que está sendo produzido. A boa prática recomenda 1 hora para cada semana de duração da Sprint.

Os ítens que devem ser abordados nesta reunião:

❶.Apresentação das entregas pela equipe

❷.Validação se a entrega foi concluída ou não (quem faz essa validação tem que ser o PO).

❸.Feedback do PO

Essa reunião não é para ser usada como “caça as bruxas”. É fundamental obter um feedback claro e construtivo do PO e, utilizar sempre como combustível para melhoria contínua.

Por fim, não menos importante, a Sprint Retrospective. Temos que nos lembrar que o PO também é membro da equipe Scrum, tal como a equipe de desenvolvimento e o Scrum Master! O PO está no comando do produto, e conta com a colaboração dos outros membros da equipe SCRUM para criar um produto ou serviço de sucesso. Caso o PO não compareça à Retrospectiva, perderá uma oportunidade ímpar de estreitar o relacionamento e melhorar a colaboração com a equipe de desenvolvimento. Além disso, participar desta reunião é um momento sem igual que permite entender por que a equipe precisa de tempo no próximo sprint, para realizar melhorias, como refatorar o script de construção ou investigar uma nova ferramenta de teste; e, talvez mais importante, auxiliar o PO a melhorar seu próprio trabalho. Imaginemos que algumas das histórias de usuário nas quais a equipe trabalhou não foram concluídas no Sprint. À primeira vista, isso parece culpa da equipe DEV. Contudo, a análise do problema pode revelar que o tamanho das histórias e a qualidade dos critérios de aceitação contribuíram para o problema. Como o PO é responsável por garantir que o Backlog do Produto esteja pronto, essa descoberta afeta diretamente o trabalho dele. Porquê? Simples! Mostrará que ele (o PO) deve melhorar o envolvimento da equipe DEV no refinamento das histórias para garantir que estejam prontas, que haja um entendimento compartilhado, que elas são viáveis e podem ser testadas.

A final de contas, o PO é bem-vindo em todas as reuniões SCRUM?

Existe um pré-conceito acerca da participação do PO em todas as reuniões SCRUM. De uma forma mais específica, algumas pessoas do time DEV, acham que o PO só é responsável por escrever histórias de usuário e pela validação do que foi entregue, não precisa “se meter” nas reuniões. Quem pensa assim, está definitivamente equivocado!

A presença do PO em qualquer cerimônia SCRUM nunca é prejudicial, sempre respeitando os critérios de atuação. Um PO presente e atuante proporciona mais segurança e potencializa o sucesso do projeto.

Reflitamos acerca disso!