O papel do Product Owner e priorização do Product Backlog

Na semana passada tivemos alguns treinamentos muito legais na Globo.com, foram três dias de curso com o Boris Gloger da Sprint-it, empresa que esta nos ajudando na adoção do SCRUM. Em dezembro passado tivemos uma série de treinamentos com o intuito de apresentar o SCRUM para as diversas áreas da empresa.

Neste ano continuamos este trabalho de formação dos profissionais da Globo.com, porém este novo round de treinamentos foi focado em um dos principais papéis dentro do SCRUM, o Product Owner (PO) e também na formação de Trainers, que realizarão os treinamentos internos para as equipes que passarão a usar SCRUM este ano.

The Scrum roles
© Copyright Conchango 2006

Apenas relembrando o papel do PO, ele é o responsável pelo Retorno do Investimento (ROI) do projeto, cabe a ele priorizar os itens no Product Backlog (PB) de forma a obter o maior retorno possível, entre as suas responsabilidades estão:

• Criar a visão
• Manter o PB estimado e priorizado
• Priorização do PB, com pelo menos 3 Sprints
• Criar as fronteiras (boundaries) que protegem o Time (Tempo, Orçamento, Visão, Padrões, etc)
• Criar um Release Plan do Produto
• Ser a interface de comunicação com os stakeholders, e outros clientes internos e externos
• Ajudar o ScrumMaster a proteger o Time
• Aceitar ou rejeitar uma funcionalidade no Sprint Review

O PO é quem deve criar a visão, mas esta deve ser compartilhada e refinada com o Time, pois é o time que deve se sentir motivado e desafiado por aquela visão. A visão deve ter algumas características básicas como: ser emocional (criar desejo), deve ser clara e concreta e deve ser difícil de alcançar.

O Product Backlog (PB) é responsabilidade do PO, mas quem deve escrever as user stories é o Time, pois este é que vai executar o Sprint Backlog e se comprometerá em entregar estas user stories, claro que o PO pode ajudar a escrevê-las, mas apenas se o time deixar. Antes deste treinamento eu achava que o PO é quem deveria escrever as user stories. É importante lembrar que o PB é formado por um misto de user stories detalhadas e estimadas e um conjunto de idéias mais amplas e sem muitos detalhes, que serão refinadas e devidamente transformadas em user stories no decorrer do processo. O Time é o responsável por estimar a complexidade das user stories, atribuindo pontos de dificuldade para cada uma delas, que chamamos de Story Points.

É importante ter pelo menos 3 Sprints priorizados e estimados, para que o time não fique “idle” na transição entre um Sprint e outro, recentemente passamos por uma situação assim na entrega de um dos releases do Globo Vídeos, por não ter um PB detalhado e priorizado o time teve de esperar alguns dias para iniciar o Sprint seguinte.

The ScrumFlow

No decorrer de cada Sprint é preciso iniciar os trabalhos de estimativa e planejamento do próximo Sprint, é uma boa prática alocar de 10% a 15% do tempo do Sprint corrente para planejar e detalhar o próximo Sprint. É responsabilidade do PO chamar as reuniões de planejamento e detalhamento dos Sprints (não confunda estas reuniões com o Sprint Planning 1 e 2) e de manter pelo menos 3 Sprints planejados e priorizados, se o PO não realizar estas reuniões o ScrumMaster deve chamar a atenção do PO e em casos extremos assumir esta responsabilidade temporariamente. Cada reunião de planejamento não deve durar mais do que 60 minutos (Timebox) e tem como objetivo manter todos no Time informados sobre possíveis mudanças nas user stories e ajustes de prioridades, além de aumentar a precisão das estimativas feitas anteriormente.

Abaixo segue uma proposta de planejamento para um backlog hipotético que entrega um release a cada 10 dias úteis, aqui vai uma dica do Boris, nunca fazer o Sprint Planning 1 e 2 em uma Segunda-Feira ou depois de um feriado, porque é preciso que todas as partes envolvidas estudem o backlog e se preparem com antecedência para estas reuniões e todos nós sabemos que é muito difícil alguém se planejar durante um final de semana ou feriado. Sendo assim a agenda ficaria assim:

• Segunda-Feira (tarde): Sprint Review e Sprint Retrospective
• Terça-Feira (manhã): Entrega do Release
• Terça-Feira (tarde): Sprint Planning 1 e Sprint Planning 2
• Quarta-Feira: Inicio do Próximo Sprint
• Mais ou menos dois dias depois do inicio do Sprint deve-se marcar uma reunião de planejamento e estimativa do próximo Sprint.
• Mais ou menos dois dias antes do final do Sprint deve-se marcar outra reunião de estimativa do próximo Sprint.

Uma vez escritas e estimadas as user stories o PO deve priorizar o PB, no treinamento aprendemos uma técnica interessante chamada de Relative Benefit. Ela funciona assim: para cada item do Backlog atribui-se um valor para o Beneficio de se ter aquela funcionalidade (variando de 0 a 10) e um valor para Penalidade de não se ter aquela funcionalidade entregue, depois somam-se estes valores e o resultado chamamos de Business Value (BV). Agora dividimos o BV pela Estimativa, que reflete a dificuldade/complexidade para se entregar aquela determinada funcionalidade, por fim o PO reordena o Backlog com base neste resultado, do maior para o menor valor.

Por exemplo, no Backlog acima temos a feature 1 que possui um beneficio baixo (1) , uma penalidade alta(9) e uma complexidade baixa(2), sendo assim o beneficio relativo desta funcionalidade é alto (5) quando comparado relativamente com os outros itens do Backlog. Esta técnica também ajuda a priorizar itens com o mesmo BV, como é o caso da feature 1 e 5, neste caso vemos que a feature 5 possui um Beneficio igual a 5, maior que o beneficio da feature 1. Seguindo este método PB acima ficaria priorizado da seguinte forma:

1. Feature 5
2. Feature 1
3. Feature 3
4. Feature 4
5. Feature 2

Esta é uma técnica muito simples que ajuda a dar uma base concreta para comparação entre as funcionalidades e assim, priorizar corretamente o PB, claro que cada caso é um caso e vão acontecer situações onde um diretor vai pedri prioridade de uma determinada funcionalidade, mas esperamos que esta seja uma exceção e não a regra.

Mas uma das mensagens mais importantes do treinamento foi com relação ao papel do PO de proteger e respeitar o Time, este é uma papel que geralmente o PO não assume e pior, como os PO’s geralmente tiveram uma experiência passada em áreas de marketing ou gerência de produtos , eles tendem a achar que a equipe de tecnologia é devagar e não tem compromisso com o produto e sempre tentam empurrar mais e mais funcionalidades pra cima do time. Isso é natural principalmente nos processos waterfall, mas em um ambiente de utiliza Scrum, esta postura do PO não pode ser aceita. Ele não deve pressionar o time para inserir mais coisas no sprint, o time é que escolhe do PB priorizado o que se compromete a entregar com qualidade até o fim do Sprint. Caso o PO entenda que o time pode entregar mais do que esta entregando, ele deve conversar com o ScrumMaster, pois a produtividade do time é um problema que o ScrumMaster deve resolver. Ao tentar empurrar mais do que o time pode entregar com qualidade, o PO começa a quebrar sua relação de confiança com o time, e o ScrumMaster deve intervir e lembrar o PO de que ele também deve proteger o time.

8 Comments

Leave a Comment

Username (required) :
Email (required) :
Web Site :
Comment :