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:
- Core – funcionalidades que atendem as necessidades básicas dos usuários. Ex.: login/logout;
- Use – funcionalidades que melhoram a usabilidade do produto;
- Engage – funcionalidades que proporcionam ao usuário mais interatividade com o produto e fazem ele voltar no futuro;
- 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!