07 Trabalhando com o Backlog do Produto
Uma das atribuições mais importantes para um Product owner é seu trabalho com o Backlog do Produto, e aqui vamos dar uma olhada nos itens a seguir;
- DEEP
- Preparação do Backlog do Produto
- Priorização do Backlog do Produto
- Preparação para o planejamento da Sprint
- Estimativa
- Dimensionamento do Backlog do Produto
7.1 DEEP
O Backlog do Produto é um documento vivo, e é responsabilidade do Product Owner mantê-lo atualizado. Normalmente se fala que o Baklog do Produto deve ser “DEEP”, o que significa:
- Detalhado apropriadamente
- Estimado
- Emergente
- Priorizado
Vamos dar uma olhada nisso:
Figura: Backlog do Produto
7.1.1 Detalhado Apropriadamente
Os itens do topo do backlog devem ser detalhados o suficiente para que o Time de desenvolvimento comece a desenvolver os itens e na parte de baixo do backlog deve haver detalhes suficientes para permitir que sejam planejados.
7.1.2 Estimado
O Scrum não apresenta uma técnica de estimativa. A Programação Extrema sugere estimar as user stories em 1, 2 ou 3 semanas como tempo ideal de desenvolvimento. A prática comum nos times ágeis é estimar em unidades relativas, normalmente pontos de story.
Independentemente da técnica de estimativa utilizada, os Product Owners geralmente requisitam que os itens sejam estimados antes de serem pedidos. Acreditamos que exista duas estimativas que devem ser obtidas: as estimativas de curso e de benefícios do negócio.
A estimativa de custo representa o montante de esforço que será necessário para que o time de entrega complete o item do backlog e apenas o time poderá adicionar uma estimativa de custo. O product owner deve fornecer os benefícios do negócio: é uma representação do valor retornado ao negócio quando o item é completado. A relação entre custo e benefício representa o retorno em investimento (ROI).
Muitos times não criam as estimativas de benefício de negócio, pedindo ao Product Owner, por sua vez, que use seus conhecimentos especializados para calcular a estimativa do benefício.
7.1.3 Emergente
O backlog é um artefato dinâmico que se modifica com o tempo assim como já foi detalhado em “Como ele muda com o tempo”.
7.1.4 Priorizado
O backlog é uma lista ordenada, o que significa que cada item na lista é parte de uma sequência sem que dois itens estejam numa mesma posição. A regra é tentar romper com a noção de que cada item no backlog é uma “prioridade”. Aplicando essa regra constantemente, o product owner será forçado a tomar decisões sobre a importância de uma story em relação a outra.
É comum organizar o backlog por uma combinação de retorno de investimento, risco, prioridade e necessidade, mas ultimamente cabe ao product owner tomar as decisões de trade-off.
7.2 Preparando o Backlog do Produto
O time (ou parte dele, incluindo o product owner) se encontra regularmente para “preparar o Backlog do Produto”, numa reunião formal ou informal que pode levar a uma das seguintes ações:
- Remover user stories que aparentam não ter mais relevância
- Criar novas user stories em resposta a novas necessidades descobertas
- Reavaliar a prioridade relativa das stories
- Atribuir estimativas a stories que ainda tenham que rececê-las
- Corrigir estimativas à luz de novas informações descobertas
- Separar as user stories de alta prioridade, mas deixá-las grosseiras a fim de se adaptarem a uma iteração futura.
Benefícios esperados
A intenção da reunião de “preparação” é a garantia de que o backlog esteja preenchido de itens relevantes, detalhados e estimados em um grau apropriado à sua prioridade, e se atualizar com o entendimento corrente do projeto ou produto e seus objetivos.
Diferente de um “documento de requisitos” mais formal, o backlog é entendido como um corpo de informação dinâmico. A título de exemplo, nem todas as user stories precisam ser refinadas no início de um projeto, ou ter estimativas detalhadas. Mas é importante que, a qualquer momento, um número “suficiente” de stories possa estar pronto para entrar no cronograma das próximas iterações.
Um projeto Ágil é, não mais que os outros, um objeto de “oscilação de escopo”, na forma de user stories que realmente não produzem valor substancial, mas que foram consideradas "boas ideias na época" e entraram no backlog para que não fossem esquecidas. Na ausência de esforços explícitos destinados a gerenciar essa inflação, ela resultaria em patologias muito conhecidas de excedentes de cronograma e orçamento.
7.3 Priorizando o Backlog do Produto
O Backlog do Produto no Scrum é normalmente uma lista de funcionalidades priorizadas, contendo curtas descrições de todas as funções desejadas no produto. Quando se aplica o Scrum, não é necessário que se inicie um projeto com um longo esforço inicial para documentar todas as funcionalidades detalhadamente.
Geralmente um Time Scrum e seu product owner começam escrevendo tudo que eles pensam da priorização do backlog. Este tipo de Backlog do Produto é normalmente mais do que suficiente para uma primeira sprint. O Backlog do Produto do Scrum então cresce e muda à medida em que se aprende sobre o produto e seus clientes.
Um backlog do Scrum típico compreende os diferentes tipos de itens:
- Funcionalidades
- Erros
- Trabalho técnico
- Conhecimento adquirido
Um time Scrum geralmente indica as funcionalidades do Backlog do Produto em forma de user stories, que são descrições curtas e simples sobre a função desejada sob a perspectiva do usuário (mais sobre user stories no capítulo 8)
Leve em consideração o seguinte no momento da priorização:
- O valor da funcionalidade para a massa
- O valor da funcionalidade para alguns da elite
- Custo do Story
- Tempo estimado de implementação
- O impacto existente em outras stories
- Custos de risco e oportunidade
A priorização da User Story pode ser feita de várias maneiras, mas aqui está uma pequena lista dos métodos normalmente utilizados.
Algumas técnicas usadas para priorizar as User Stories ou requisitos no Backlog do Produto priorizado:
- Ranking de priorização relativa: Uma simples listagem de User Stories em ordem de prioridades é um método efetivo para determinar as User Stories desejadas para cada iteração ou lançamento de produto ou serviço. A proposta é criar uma lista simples e única com a meta da priorização de funcionalidades, ao invés de se distrair com vários esquemas de priorização.
Esta lista simples também proporciona uma base para a incorporação de mudanças e riscos identificados quando necessário. Cada mudança ou risco identificado podem ser inseridos na lista com base em sua prioridade em relação a outras User Stories na lista. Normalmente, novas mudanças serão inclusas às expensas de funcionalidades as quais foram dadas prioridades mais baixas.
Definir as Funcionalidades Mínimas Comercializáveis (MMF, de Minimum Marketable Features) é extremamente importante durante este processo, então esse primeiro lançamento ou iteração acontece o mais cedo possível, levando ao aumento do ROI. Normalmente, essas User Stories estarão rankeadas como prioridade máxima.
- Método de priorização MoSCoW: O método de priorização MoSCoW tem seu nome derivado das primeiras letras das frases “Deve ter” (Must Have), “Pode ter” (should have) e “Não terá” (Won’t have). Este método é geralmente mais efetivo que os esquemas mais simples. Os rótulos estão em ordem decrescente de prioridade, com as User Stories do “Must Have” sendo aquelas sem as quais o produto não terá valor e “Won’t Have” sendo aquelas que, apesar de serem boas de se ter, sua inclusão não se faz necessária.
- Comparação em pares: Nesta técnica, uma lista com todas as User Stories do Backlog do Produto priorizado é preparada. A seguir, cada User Story é pega individualmente e comparada com outras User Stories na lista, um de cada vez. A cada vez, duas User Stories são comparadas, uma decisão é tomada sobre qual das duas é mais importante. Durante esse processo, uma lista priorizada de User Stories será criada.
- Método dos 100 pontos: Dean Leffingwell e Don Widrig (2003) desenvolveram o Método dos 100 pontos. Ele envolve dar ao cliente 100 pontos para que ele use para votar nas User Stories mais importantes. O objetivo é dar mais peso as User Stories que tem prioridade máxima comparadas a outras User Stories disponíveis. Cada membro do grupo atribui pontos para várias User Stories, dando mais pontos àquelas que eles sintam que sejam mais importantes. Ao final do processo de votação, a priorização é determinada através do cálculo dos pontos totais atribuídos a cada User Story.
- Análise Kano
Considere os itens a seguir quando da priorização:
- O valor da funcionalidade para as massas
- O valor da funcionalidade para poucos da elite
- Custo do Story
- Tempo estimado para implementação
- O impacto que isso tem em outros stories
- Custos de riscos e oportunidades
De maneira interessante, as funcionalidades normalmente vão caindo na lista de classificação à medida em que o tempo passa. Clientes vão esperar funcionalidades (por exemplo, câmeras nos celulares) e essas funcionalidades vão mudar de serem excitantes/encantadores para satisfatórias e enventualmente para não satisfatórias.
Existem outros métodos como Triagem de Tema, Pontuação de Tema, Ponderação relativa e Análise Financeira, os quais serão aprofundados no nível Avançado do curso de Product Owner.
