Trabalhar bem com o backlog é extremamente importante; não só para a carreira de um gerente de produtos, como também (e principalmente), para o bom andamento de um produto. Manter o backlog refinado, devidamente preparado para o trabalho do time e com as dependências externas e internas mapeadas garante um roadmap mais realista, refletindo valor para os clientes e para o negócio, e faz parte da difícil vida de um Product Owner.

Considero o backlog um ser que vai se adaptando e se construindo de acordo com o andamento das coisas, além de ser altamente volátil e mudar constantemente. Por isso, precisa de uma atenção especial e diária. Imagine se ao refinar seu backlog você não faz o mapeamento de dependências? Quando o time for fazer o planning, surgirão muitas dependências externas de atividades que você priorizou e será inviável fazer aquelas tarefas de valor naquele momento. Como estar preparado para isso?

Para facilitar a vida dos meus caros colegas de profissão, resolvi postar aqui algumas boas técnicas para ajudar nesta tarefa.

Story Mapping

Essa é uma das técnicas que mais uso, especialmente quando o ambiente e as dependências estão “sob controle”. Criada por Jeff Patton, a ideia principal é de que uma simples lista de backlog é uma forma horrível de priorizar o que precisa ser feito. Precisa-se de uma boa estrutura. Basicamente, o Story Mapping funciona assim:

• Um eixo horizontal que indica tempo;
• Um eixo vertical que indica necessidade;
• Primeiro organizamos as atividades, começando pelas que levam menos tempo e são mais importantes, no eixo horizontal;
• Depois, colocamos logo abaixo das atividades as histórias e tarefas, verticalmente e horizontalmente.

Após as tarefas estarem organizadas na planilha ou quadro, o próximo passo é fazer o corte de releases.

Esta técnica é extremamente visual. Caso consiga usar um quadro e deixar na parede, seria ótimo, pois todos que quiserem saber o andamento do produto só precisam olhar para o quadro. É muito bom para quando o produto estiver na fase de MVP, porque facilita a visualização de cada MVP separadamente e isso ajuda a alinhar a expectativa dos stakeholders e manter o time alinhado com o propósito do negócio.

Outro ponto importante é que o Story Mapping está relativamente atrelado à jornada do usuário e, olhando nesse nível, novas oportunidades de negócio, produto e melhorias nos pontos de contato podem surgir.

Value versus Risk

Um modo clássico de priorizar o backlog é fazendo a comparação entre valor e risco dos itens. Esta técnica é indicada para novos produtos ou novas features. Funciona basicamente da seguinte forma:

Temos quatro quadrantes de classificação:

• Alto risco/baixo valor;
• Alto risco/alto valor;
• Baixo risco/baixo valor;
• Baixo risco/alto valor.

Não existe uma fórmula definida para se classificar risco, porém sugiro pensar em itens que vão levar muito tempo, itens muito complexos e os que podem precisar de desenvolvimento em outra linguagem de programação ou com grandes dificuldades técnicas.

Valor versus esforço

Seguindo a mesma linha do Value versus Risk, temos a técnica que confronta valor e esforço, na qual a matriz valor indica o valor para o negócio e a matriz esforço indica o esforço de desenvolvimento da feature. Obviamente, o que tiver mais valor e menos esforço é ótimo, e o que é de baixo valor e muito esforço deve ser evitado. É geralmente utilizada para priorizar backlogs em times pequenos e que ainda não se conhece o grau de maturidade com o qual vão trabalhar.

Scorecard

Esta é outra técnica bastante usada, porém você precisa alinhar com os stakeholders os critérios para que seja mais eficaz. Consiste em um cartão no qual são definidos os critérios e seus respectivos pesos, além das features. Cada critério relacionado àquela feature recebe uma nota e, após realizar o cálculo dos pesos, teremos as notas de cada feature. Aí é só ordenar do maior para o menor.

Detalhadamente, funciona assim:

• Para cada categoria, dê uma nota de 0 a 100. Notas negativas são permitidas e quando usadas geralmente indicam um alto risco para a feature em uma categoria.
• A primeira feature da lista, Monthly Report, recebeu nota 90 na categoria Customer Engagement, o que denota grande impacto. O valor total deve ser inserido na coluna de prioridade (Priority), e é calculado da seguinte forma: 90*20% + 90*10% + 50*30% + 20*40% = 50.

Assim, teremos todas as features que vamos atacar, priorizadas.

É importante salientar que ao selecionar as categorias precisamos considerar outros departamentos envolvidos para conseguir dar o valor real da feature, ou até mapear dependências externas.

Systemico Model

Esta é uma técnica que se baseia no valor para o cliente. Os criadores do framework acreditam que a geração de valor não consiste em um processo linear isolado, mas sim em um processo sistêmico e holístico.

Essa técnica é baseada no Story Mapping. Mudam as dimensões e os itens são organizados de acordo com o nível de objetivo do usuário e engajamento. A dimensão de engajamento possui quatro categorias:

1. Core – funcionalidades que atendem as necessidades básicas dos usuários. Ex.: login/logout;
2. Use – funcionalidades que melhoram a usabilidade do produto;
3. Engage – funcionalidades que proporcionam ao usuário mais interatividade com o produto e fazem ele voltar no futuro;
4. Explore – funcionalidades que tornam o usuário fiel ao seu produto. Ex.: plano de recompensas, serviços personalizados, etc.

Os itens desta categoria não significam prioridades, servem para manter o foco na proposta do produto atrelada aos objetivos do cliente. Os itens, então, são inseridos de acordo com os níveis de objetivo do usuário e categorias de engajamento e, assim como no Story Mapping, é possível criar os releases.

MoSCoW

Esta técnica é utilizada para buscar o alinhamento do que é mais importante para clientes e stakeholders. Aconselho o uso para pequenos projetos internos ou produtos com poucos stakeholders.

O termo é um acrônimo, no qual cada consoante indica uma categoria de priorização: MoSCoW – Must, Should, Could e Won’t (colocaram a vogal “o” para facilitar a memorização).

Funciona da seguinte forma:

Primeiro, é preciso categorizar as histórias e tarefas do backlog nas seguintes categorias:

• Must – contém tudo o que um release “precisa ter”, todos os itens críticos. Caso algum item falte aqui, a release será considerada um fracasso;
• Should – Aqui vão os itens que são importantes, mas não são críticos para a release. São aqueles itens que geralmente consideramos que seria legal ter;
• Could – Aqui estão todos os itens que são desejados, mas não são necessários para a release. Geralmente são pequenos incrementos de baixo custo;
• Won’t – Aqui vão os itens que têm pouca importância ou ainda não estão alinhados com a estratégia do produto. Podem ser considerados em releases futuros ou até mesmo serem invalidados.

Conclusão

Sei que manter um backlog atualizado e que reflete as necessidades do negócio e dos clientes é trabalhoso mas, em contrapartida, tê-lo assim aumenta as chances de sucesso, além de deixar todos, time e stakeholders, cientes do estado do produto. Creio que o uso de alguma destas técnicas vai ajudar bastante nesta árdua tarefa.

E aí, ficou com alguma dúvida sobre o assunto ou deseja acrescentar algo? Pode me procurar ou deixe seu comentário abaixo.

Até a próxima!