Técnicas para priorização de itens de backlogs de produto

Existem uma infinidade de técnicas para priorização de produto, hoje compartilho com vocês algumas que eu já utilizei em alguns contextos e organizações:

Bubble sort

Na faculdade, aprendemos a ordenar arrays utilizando o algoritmo bubble sort. A ideia é analisar itens comparativamente. Funciona muito bem para listas pequenas de itens com poucos participantes, entre 10 a 20. Se inicia com dois itens da lista e entre eles sai qual é o mais prioritário. Feito isto, o terceiro item é comparado a nova lista já priorizada (com dois itens). E assim sucessivamente, até o final.

Ordenação por turnos

Seguindo a mesma linha de raciocínio, o objetivo é que o coletivo crie uma lista ordenada de itens, é importante seguir um conjunto de regras simples para que o trabalho possa fluir de forma adequada. São elas:

  • Uma pessoa só pode fazer um movimento por vez;
  • Existem dois tipos de movimento possíveis:
    • Pegar um card da lista não ordenada e colocá-lo no fim da lista de priorização;
    • Pegar um card da lista ordenada e movê-lo de posição
  • A única restrição: não fazer o movimento contrário ao recém executado.

O número de turnos necessários para a conclusão da dinâmica varia de caso a caso, sendo dependente, primeiramente, pelo número de itens existentes. Com isso, uma mesma pessoa poderá ter múltiplos turnos.

[texto acima foi copiado de: Ordenção por turnos]

Merit Money para Priorização

Merit Money é um conceito visto no Management 3.0, mas já foi utilizado com outros nomes e de outras formas no passado. A ideia aqui é ter um momento para “investir” na priorização de funcionalidades e requisitos. Tanto membros quanto stakeholders podem receber uma quantia (que pode ser ajustada de forma diferente para não ser decisões totalmente democráticas) para colocar os seus “dinheiros” para que funcionalidades sejam implementadas. A dinâmica seria executada na forma de que alguém de negócio apresentaria as funcionalidades, os profissionais teriam um tempo para distribuir o seu dinheiro nas funcionalidades e do resultado da dinâmica, serviria de input para a priorização de negócio. Nem todo produto/serviço possui um contexto que é aderente a esta proposta.

Priorização MoSCoW

MoSCoW é um acrônimo, que condensa as palavras em inglês: Must / Should / Could / Would. Must podemos traduzir para Obrigatórios ou não negociáveis, são aqueles que tem de ser desenvolvidos e a área de negócio já validou a necessidade dos requisitos. Should podemos traduzir para Deveríamos, são aqueles itens que nós deveríamos desenvolver pois podem impactar no desenvolvimento ou atrapalhar futuras entregas (alguns Débitos técnicos / dívidas técnicas podem ser classificados neste nível). Could são aqueles itens que Poderiam ser feitos pela equipe e não impactam negativamente outras entregas. Would na verdade vem de “Would be nice” ou seja, são aqueles itens que seria positivo se fossem resolvidos mas não são prioritários.

MoSCoW é um artifício que também pode ser utilizado com Gestão Visual. É possível classificar os itens de trabalho que estão em andamento no seu Quadro Scrum ou no seu Quadro Kanban nestas 4 diferentes categorias.

Esforço Técnico x ROI + Certeza de Negócio x Certeza Técnica

roi x esforco.pngbus certainty x tech certainty.png

[Fotos: Livro Direto ao Ponto]

Estes dois Canvas podem ser utilizados para classificar tarefas, histórias de usuário ou funcionalidades. Ele consiste em duas etapas de classificação que servem como insumos para uma priorização posterior.

O primeiro (esquerda) tem dois eixos: Valor de negócio ou Retorno sobre o investimento (ROI – Return Over Investment) e Esforço Técnico que é o esforço necessário para implementar aquele item. Cada eixo, possui três níveis: Baixo ($ / E), Médio ($$ / EE) e Alto ($$$ / EEE). A ideia é que um grupo que contenha especialistas do domínio de negócio e o time que irá desenvolver consiga debater sobre cada item, tendo um entendimento de alto nível sobre cada tarefa. Após cada debate, o item deve receber anotações de Valor de Negócio e Esforço Técnico.

Uma dica prática é não escrever as palavras Baixo, Médio e Alto ou até mesmo substituir pelas palavras: alto, muito alto e altíssimo. Teoricamente, uma tarefa, história ou funcionalidade de baixo valor de negócio não deveria nem ter chegado neste ponto de conversa.

O segundo (direita) tem dois eixos: Certeza de Negócio sobre o conteúdo da tarefa, história de usuário ou funcionalidade (Business Certainty) e Certeza Técnica que consiste de experiências prévias e conhecimento da equipe de desenvolvimento sobre aquele item de desenvolvimento. Cada eixo, possui três níveis: Baixo, Médio e Alto. Neste canvas, a ideia é atribuir uma cor a cada item (Vermelho, Amarelo, Verde) que representa o risco de cada item. As cores se dão conforme apresentado no Canvas, por exemplo: itens  aonde existe uma Alta certeza de Negócio e Técnica o cartão é atribuído como Verde, ou seja, de baixo risco.

 

Quais outras técnicas de priorização você utiliza?

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s