<center><!– LOMADEE – BEGIN –>
<script type=”text/javascript”>// <![CDATA[
lmd_source=”34554113″; lmd_si=”33530810″; lmd_pu=”22493390″; lmd_c=”BR”; lmd_wi=”728″; lmd_he=”90″;
// ]]></script>
<script src=”http://image.lomadee.com/js/ad_lomadee.js” type=”text/javascript”></script>
<!– LOMADEE – END –></center>

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!
Source: IMASTER