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 Scrum 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:
| Funcionalidades | Benefícios | Penalidades | 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 topdown 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.