Concrete Logo
Hamburger button

Algumas técnicas de priorização do Backlog

  • Blog
  • 19 de Fevereiro de 2016
Share

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, é altamente volátil e muda constantemente. Por isso, precisa de uma atenção especial, 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 é que uma simples lista de backlog é uma forma horrível de priorizar o que precisa ser feito, é necessária 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;image03

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, será ó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 vs 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

image02

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 itens que podem precisar de desenvolvimento em outra linguagem de programação ou com grandes dificuldades técnicas.

Valor vs Esforço

Seguindo a mesma linha do Value vs 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 nos quais times pequenos e que ainda não se conhece o grau de maturidade 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.

image05

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.

image04

 

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 4 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).

image00

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!