O Product Owner assume
papel de suma importância no processo de trabalho de uma equipe, tendo como
principais atribuições:

• a definição dos
  itens que compõem o Product
  Backlog;
• a priorização dos Sprint
  Planning Meetings;
• a
  definição das funcionalidades do produto;
• a visão do
  produto final que deverá ser entregue;
• a
  definição das datas de liberação de conteúdo dos releases;
• o retorno
  de investimento (ROI) do produto;
• a
  definição de um canal de comunicação entre os stakeholders;
• a criação
  de um plano de proteção do TIME (Tempo, Orçamento, Visão, Padrões);
• a
  priorização das funcionalidades de acordo com o valor que agregam ao produto;
• os ajustes
  de funcionalidades e prioridades a cada Sprint;
• a
  aceitação ou rejeição os resultados de trabalho.

Dentre as
atribuições do Product Owner, a mais desafiadora com certeza é a criação da
visão, pois ela deverá ser compartilhada e refinada com a equipe, e deve
contribuir para que a equipe se sinta desafiada a alcançar os objetivos
traçados.

Além disso, a
primeira formalidade do Scrum, o Sprint Planning, também fica sob a
responsabilidade do Product Owner.

A equipe, por sua
vez, analisa o Product Backlog priorizado pelo
Project Owner, devendo realizar uma revisão dos itens com prioridade mais alta
e se comprometer com a entrega desses itens ao final de uma iteração ou Sprint.
Nasce então o Sprint Backlog.

É nesse momento que
a equipe e o Product Owner realizam um compromisso, no qual a equipe deverá
executar o conjunto de atividades definidas no Sprint Backlog, e o Product
Owner, por sua vez, assume o compromisso de não trazer novos requisitos para a
equipe durante o Sprint. Podem ocorrer mudanças de requisitos e tanto a equipe
como o Product Owner devem ter em mente que mudanças são sempre bem-vindas,
pois representam oportunidades. Mas a regra é que essas mudanças deverão ser
tratadas fora do Sprint, de forma que a partir do momento em que a equipe começa
a trabalhar em um determinado Sprint, deve manter-se concentrada nele para
alcançar sucesso no objetivo que foi traçado. Durante o Sprint, novos requisitos
não serão aceitos.

O Product Backlog,
apesar de ser de responsabilidade do Product Owner, será administrado pela
equipe no que diz respeito a sua manutenção, através do registro das user
stories. Embora haja alguns Product Owners que escrevam user stories, é preciso
esclarecer que essas são de responsabilidade da equipe e se o Product Owner o
fizer deve ser colaborativamente.

Inicialmente, no
Product Backlog, estão inseridas todas as principais funcionalidades do produto
final, além é claro de algumas user stories bastante detalhadas, que
normalmente refletem a ênfase que está sendo dada ao produto final, mas existirá
também em sua composição uma grande parte de ideias amplas, mas ainda sem
tantos detalhes. Essas ideias, ao longo do trabalho, devem ser compreendidas,
detalhadas, analisadas e paulatinamente devem tornar-se user stories.

A
compreensão do processo de negócio que está sendo desenvolvido, do produto
final que será entregue e das carências dos usuários ajudarão a equipe a focar
na solução ideal. A equipe deve ter em mente, ainda, a necessidade de estimar a
complexidade das user stories, devendo controlar também os story points, que
determinarão os pontos onde houver maior complexidade.

Tendo recebido e
analisado a priorização que o Product Owner fez inicialmente, a equipe deve
iniciar o Sprint, devendo transferir as tarefas prioritárias do Product Backlog
para o Sprint Backlog.

É muito importante que
o Product Owner tenha priorizado ao menos uns 3 Sprints, evitando com isso que
a equipe fique sem tarefas planejadas entre uma e outra iteração. Em alguns
casos, a equipe e o próprio Product Owner se esquecem de ter Sprints futuros planejados
e ao terminar o Sprint atual a equipe não tem condições de iniciar o seguinte.

Durante a execução
de um Sprint, o Srum Master deve acompanhar a atualização do Sprint Backlog, verificando
as tarefas que estão em execução, tarefas que já foram encerradas e o tempo
estimado para a conclusão das demais tarefas do Sprint. Como esse tempo é
estimado, pode, obviamente, sofrer algum tipo de alteração. Os resultados dessa
medição são apurados dia-a-dia e podem ser comunicados através do Sprint Burndown
Chart, que demonstra a evolução das tarefas ao longo do Sprint.

Uma questão
importante que muitas vezes deixa de ser observada é a alocação de algum tempo
do Sprint atual para planejamento do próximo Sprint. Quando esse tempo não é
alocado, deve ocorrer um intervalo entre um Sprint e outro, ocasionando uma
parada inesperada para a equipe. O Product Owner deve ficar atento, também, para
no momento em que definir 3 Sprints, ter em mente algumas reuniões de
acompanhamento e revisão. É responsabilidade do Scrum Master observar os
resultados dessas reuniões de acompanhamento e revisão, para assegurar que
todos os processos estão bem orientados. Vale ressaltar, nesse ponto, que as
reuniões de acompanhamento e revisão devem durar entre 40 e 60 minutos, devem
ter foco em comunicar eventuais mudanças nas prioridades do Sprint que está
sendo executado e validarem se as estimativas de tempo estão em conformidade com
o planejado.

Quando a equipe se
aproxima da conclusão do Sprint e consequentemente da entrega do release,
deve-se realizar o Sprint Review Meeting, que é o momento em que a equipe
demonstra as funcionalidades que foram criadas durante o Sprint. Essa
demonstração deve envolver, além da equipe do projeto, o Scrum Master, o Product
Owner e os Clientes.

Tendo ocorrido o
Sprint Review, a equipe deve realizar o Sprint Retrospective, no qual poderão
analisar as lições aprendidas durante o Sprint, colocar em práticas novas
descobertas favoráveis ao projeto e eliminar aquilo que não agregou valor.

Segue abaixo um
exemplo, para melhor compreensão de um Sprint em que há entregas de releases a
cada 10 dias de trabalho:

• dia 01 – Sprint
  Planning;
• dia 02 – Início do
  Sprint;
• dia 04 – reunião
  de acompanhamento e revisão (duração máxima 1 hora);
• dia 05 – planejar
  próximo Sprint (duração máxima 1 hora);
• dia 07 – reunião
  de acompanhamento e revisão (duração máxima 1 hora);
• dia 09 – Sprint Review e Sprint Retrospective;
• dia 10 – Entrega
  do release.

 O tempo restante não
detalhado no exemplo acima será utilizado para execução das funcionalidades do
Sprint.

Até esse ponto deste
artigo, eu acredito que a grande maioria das equipes ágeis está bem
familiarizada, e deve inclusive conviver muito de perto. Obviamente, há sempre,
alguma variação ou adaptação do modelo conceitual para a aplicação no dia-a-dia
de cada projeto e/ou cultura organizacional, o que na prática não é prejudicial
se mantidas as prerrogativas essenciais.

Mas a grande questão
é como o Product Owner deve priorizar as tarefas do Product Backlog, em
especial quando há funcionalidades a serem construídas que não são tão
dependentes umas das outras, ou ainda quando mesmo havendo alguma dependência
as funcionalidades aparecem como concorrentes. Ou seja, dependemos da conclusão
de várias funcionalidades paralelamente para alcançarmos um ponto do produto
final, no qual  essas funcionalidades comecem a ser unificadas.

Diante do desafio de
priorização das funcionalidades, existe uma técnica denominada Relative
Benefit, na qual cada funcionalidade do Product Backlog recebe um valor de
“benefício” e um valor de “penalidade” que pode variar, por exemplo, de 1 a 5. Os
valores de “benefício” indicam qual a agregação de valor dessa funcionalidade
no Product Backlog, e valores de “penalidade” indicam em quanto o Product
Backlog será impactado caso essa funcionalidade não seja entregue no prazo.

O
resultado da soma dos valores (benefícios + penalidades) recebe o nome de
Business Value, que será dividido pela “estimativa” gerando o grau de
complexidade para entrega de cada uma das funcionalidades. Após descobrir a
complexidade, o Product Owner deverá classificar as funcionalidades da mais
complexa para a menos complexa. Veja no exemplo abaixo:

Funcionalidade	Benefício	Penalidade	Business_Value	Estimativa	Complexidade
Func_01	1	4	5	5	1,0
Func_02	2	1	3	6	0,5
Func_03	3	5	8	2	4,0
Func_04	4	4	8	8	1,0
Func_05	2	1	3	1	3,0

 No exemplo acima,
ficou evidente que a complexidade é realmente uma determinante para a
priorização das funcionalidades e com isso para a definição do Product Backlog,
que ficaria priorizada da seguinte forma:

Prioridade	Funcionalidade
1	Func_03
2	Func_05
3	Func_04
4	Func_01
5	Func_02

 Como as
funcionalidades Func_01 e Func_04 apresentaram a mesma complexidade,
estabelecemos então que a prioridade deve ser adotada a partir do maior “benefício”
que nesse caso ficou evidenciado que o “benefício” da Func_04 é maior que da
Func_01, portanto, na priorização, seguimos essa linha de conduta, primeiro a “complexidade”
e depois o “benefício”.

Haverá situações em
que apenas a técnica de benefícios será insuficiente para determinar a
priorização, como por exemplo, quando houver uma decisão top-down em que a
diretoria determinará que uma funcionalidade terá prioridade acima das demais.
Vale ressaltar que, mesmo em casos como esse, que serão tratados como exceção, a
técnica de benefícios demonstrará eventualmente que há itens mais complexos ou
que oferecem mais benefícios do que a funcionalidade solicitada pela diretoria,
caso haja necessidade de argumentação dessa exceção, prevalecendo sempre o bom
senso na questão.

Apesar de uma
técnica simples, ela é muito útil e tem bases sólidas, que poderão inclusive
gerar um histórico da tomada de decisão relativa à priorização das
funcionalidades do Product Backlog. Uma vez construída uma base de conhecimento
histórico, poderemos inclusive basear novas decisões a partir desse modelo
conceitual de priorização.