5 técnicas de priorização: Organize seu backlog

Conheça as técnicas, entenda como usá-las da melhor forma, e descubra como eu organizei um backlog com mais de 700 itens

Para entregar valor de forma contínua, é muito importante manter o backlog do produto organizado, e essa não é uma tarefa simples. Existem diversos métodos de priorização, e possivelmente você já utilizou algum deles.

Um backlog bem organizado não deveria conter mais de 700 itens, como foi o que aconteceu comigo. Ao conversar com outras pessoas, eu descobri que esse problema é mais comum do que eu imaginava, e foi por isso que resolvi compartilhar a minha experiência com você.

Antes de me aprofundar no tema, eu busquei no Scrum Guide alguns conceitos fundamentais para o bom entendimento deste artigo.

O que é o Backlog do Produto?

“O Product Backlog é uma lista ordenada e emergente do que é necessário para melhorar o produto.”

Quem é o responsável pelo Backlog?

“O Product Owner também é responsável pelo gerenciamento eficaz do Product Backlog, que inclui:

● Desenvolver e comunicar explicitamente a meta do produto;
● Criar e comunicar claramente os itens do Product Backlog;
● Ordenar os itens do Product Backlog; e,
● Garantir que o Product Backlog seja transparente, visível e compreensível.

O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o Product Owner ainda é o responsável.”

Quando o Backlog deve ser revisado?

“O Refinamento do Backlog é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho. Os atributos geralmente variam de acordo com o domínio de trabalho.”

Você já deve ter olhado para o seu Backlog e pensado:

• “Como vou organizar isso?”
• “O que nesta lista ainda faz sentido?”
• "Vai levar uma vida para organizar isso aqui!”

Foi nessa situação que me encontrei há algum tempo atrás. Nossa loja virtual já existia há mais de 4 anos, e havia passado por algumas reformulações importantes, mas a empresa que cuidava da nossa plataforma de e-commerce anunciou que não prestaria mais este tipo de serviço, e nos deu um prazo para buscar uma alternativa.

Nos envolvemos então em um desafio corporativo dos grandes. Precisávamos construir uma loja nova, do zero e em um prazo curto. Nossa meta era reduzir ao máximo o impacto da transição em relação a operação da empresa.

Começamos o projeto com uma grande lista de itens para desenvolver, e a cada Sprint novos itens iam surgindo para contemplar novas funcionalidades, correções, melhorias, débitos técnicos, etc.

O topo do backlog estava a todo tempo sendo refinado, pois era ali que estavam os itens mais importantes. Na parte de baixo estavam os itens de menor valor e/ou de menor prioridade, e infelizmente não conseguimos dar tanta atenção a eles. E assim, a lista foi crescendo de forma desorganizada.

Conseguimos entregar a nova loja em Outubro de 2019, mas nos meses seguintes continuamos desenvolvendo funcionalidades que havíamos despriorizado e corrigindo os defeitos que apareciam em produção. Com o go-live da nova plataforma, surgiu também um aumento no volume de demandas vindas de todos os departamentos da empresa.

Com o passar do tempo, o topo do backlog que representava 80% do nosso volume de itens, passou a representar apenas 20%. A parte menos prioritária da lista de atividades seguiu crescendo de forma desordenada, diminuindo ainda mais a nossa visibilidade e compreensão do que precisava ser feito.

Eu demorei muito tempo para conseguir organizar a casa. Depois de mais de 1 ano de vida da nossa nova loja, eu finalmente consegui reservar um espaço nas sprints para executar essa atividade. Mas por onde eu começaria? Quais eram as técnicas disponíveis? Como eu escolheria uma entre elas?

Decidi então me aprofundar nos estudos e descobri que existem diversas formas de se organizar um backlog. Nos parágrafos abaixo eu te contarei um pouco do que descobri sobre os métodos que estudei.

Método 1: Valor de Negócio x Risco

Um dos métodos mais comuns de priorização é analisar o valor de negócio e o risco de cada item.

Para priorizar, classifique e posicione os itens entre:

• Alto risco / Alto valor: Faça primeiro estes itens
• Baixo risco / Alto valor: Faça em seguida estes itens
• Baixo risco / Baixo valor: Faça por último estes itens
• Alto risco / Baixo valor: Evite fazer estes itens

Uma boa forma de analisar os riscos é avaliar:

• Risco de valor: O usuário vai utilizar? Vai ser bom pra ele?
• Risco de usabilidade: O usuário conseguirá utilizar?
• Risco de viabilidade técnica: O time conseguirá desenvolver isso com a tecnologia, tempo e habilidades que possui?
• Risco de viabilidade de negócio: Isso está de acordo com as regulamentações do setor e não conflita com funcionalidades já existentes?

Prós

• É um método relativamente simples, pois não envolve fórmulas complexas.
• Ajuda a focar no que tem mais valor. Atacar os itens mais arriscados primeiro é uma boa estratégia principalmente no início do projeto, pois se precisar de uma mudança de rota, é importante descobrir cedo para diminuir o desperdício.
• Os critérios risco e valor de negócio são flexíveis, de forma que pode ser adaptado para Valor x Custo, Valor x Esforço, Custo x Benefício, entre outros.

Contras

• Em alguns contextos apenas 2 critérios de avaliação não serão suficientes.

Método 2: Testes de Suposição

Este método define a prioridade a partir dos resultados da validação de uma hipótese ou suposição, e também da relevância para o usuário final. É necessário definir os valores das escalas de cada critério, como no exemplo abaixo:

T = O quanto a suposição foi testada

U = Relevância para o usuário

A prioridade é o resultado da soma destes dois critérios.

Prós

• Evita que seja empregado esforço em hipóteses não exploradas.
• O benefício para o usuário tem grande peso.
• Seus critérios priorizam a geração de valor para o cliente

Contras

• Poucos times tem um processo estruturado de levantamento e validação de hipóteses antes do desenvolvimento
• Não considera o valor de negócio para empresa

Método 3: BUC

O método BUC analisa os benefícios para o negócio e para o usuário enquanto mantém um olhar para o custo.

Para cada critério deve ser definida uma escala de valor (ex.: 1 a 5). Algumas perguntas podem ajudar a avaliar cada um dos critérios:

Benefícios de negócio (Business Benefits): Quanta receita essa funcionalidade poderá gerar? Reduzirá os custos da empresa? Trará mais clientes?

Benefícios para o usuário (User Benefits): A experiência do usuário será melhor? Ele ficará mais satisfeito? Ele quer utilizar essa funcionalidade? Ele conseguirá utilizar essa funcionalidade?

Custo (Cost): Quanto tempo será necessário? Quanto dinheiro irá custar? Quantos recursos irá precisar?

Prós

• Concilia os interesses do usuário e da empresa
• Possibilita simplificar negócios complexos reduzindo a estes 3 critérios
• Pode ajudar a identificar itens que “intuitivamente” teriam uma priorização muito diferente

Contras

• Para ter mais precisão nos benefícios e custos é necessário envolver mais pessoas e nem sempre existe essa disponibilidade.

Método 4: Scorecard

O Scorecard visa priorizar de acordo com um conjunto de critérios pré-definidos com as partes interessadas.

Primeiramente devem ser definidos os critérios e em seguida definir o peso de cada um deles (os pesos somados devem totalizar 100%). Não se esqueça de alinhar com as partes interessadas antes de analisar os itens do backlog, isso pode evitar muito retrabalho.

Cada critério avaliado recebe uma nota de 0 a 100. Em casos que a funcionalidade representa algum risco do ponto de vista daquele critério pode ser utilizada uma nota com valor negativo.

Para calcular a prioridade, primeiramente cada nota deve ser multiplicada pelo peso, e o valor da prioridade será a soma de cada nota multiplicada pelo peso, conforme a fórmula abaixo:

Prioridade = SOMA (Nota do critério * (peso/100))

Prós

• Consegue analisar uma ampla quantidade de critérios
• Alinhamento com as partes envolvidas

Contras

• Para ter mais precisão em diversos critérios, pode ser necessário envolver mais pessoas e nem sempre existe essa disponibilidade.
• A escala de valor é muito extensa dificultando a definição de significados claros para os valores das escalas, e certamente impactará a precisão.

Método 5: MoSCoW

O nome MoSCoW vem do acrônimo do nome (em inglês) das categorias de priorização que este método utiliza (exceto as letras minúsculas).

As categorias são Must-Haves, Should-Haves, Can-Haves e Won’t-Haves. E esses são os critérios para definir em qual categoria entra cada item:

Must-haves:

São itens críticos, eles são os responsáveis diretos ou indiretos pelas principais entregas de valor. Se algum item desta categoria não for concluído, a entrega certamente será considerada um fracasso, pois poderá bloquear outras atividades e até o projeto inteiro.

Se pergunte “Podemos seguir com o projeto sem a entrega desta funcionalidade?”, se a resposta for NÃO, então deve ser categorizado como MUST.

Não deve conter mais de 60% do Backlog.

Should-haves:

São os itens de prioridade secundária, que não afetarão a entrega. São importantes, mas não cruciais para a entrega. Geralmente é possível contornar esses itens de alguma forma.

Se pergunte “Podemos seguir em frente com o projeto se a entrega desta funcionalidade atrasar um pouco?”, se a resposta for SIM, então deve ser categorizado como SHOULD.

Could-haves:

São itens desejados, porém de menor importância que as duas categorias anteriores. A não entrega deste item deve ter um baixo impacto. Geralmente são pequenas atividades de baixo custo que são realizadas quando não há uma restrição muito grande de tempo.

Se pergunte “Podemos abrir mão desta atividade até a entrega do projeto?”, se a resposta for SIM, então deve ser categorizado como COULD.

Esta categoria deve ter no máximo 20% dos itens.

Won’t-haves (This time):

São atividades que são inviáveis de entregar no momento (restrições de orçamento, prazo, alinhamento, etc.), porém existe a possibilidade de ser desenvolvido em algum outro momento futuro que apresente condições mais favoráveis.

Se pergunte “Podemos reintroduzir esta atividade quando o cenário for mais favorável?”, se a resposta for SIM, então deve ser categorizado como WON’T.

Prós

• Categorização simples
• Utiliza linguagem humana (em inglês) para priorizar

Contras

• Apesar de poder ser utilizada para projetos com ou sem prazo definido, funciona melhor se aplicada em um contexto em que têm prazos estabelecidos
• Se houver uma quantidade grande de itens, ainda pode ser necessário priorizar dentro de cada categoria

Outros métodos

• Kano Model: Analisa a satisfação do cliente em relação à performance do produto, categorizando as atividades como Atrativos, unidimensionais (ou de desempenho), obrigatórios (ou necessários) e indiferentes.

• Story Mapping: Utilizado principalmente nas fases iniciais do projeto e focada na experiência do usuário. O mapa tem a jornada do cliente no eixo horizontal, e no eixo dentro de cada jornada as atividades são ordenadas por prioridade top-down, posteriormente organizadas em releases.

• Buy a Feature (Compre uma funcionalidade): Com dinâmica de jogo em grupo, cada atividade deve receber um preço (geralmente baseado no esforço). O preço de todas as atividades é somado e dividido pela quantidade de envolvidos na priorização, esse é o valor que cada participante a priorização recebe em dinheiro fictício para escolher quais atividades quer comprar.
• RICE: Utiliza os critérios Reach(alcance), Impact(impacto), Confidence (confiança) e Effort (esforço) para definir a prioridade através da fórmula: (Reach x Impact x Confidence) / Effort

Qual é o melhor método?

Você olha para o seu Backlog cheio de itens que precisam ser revisados e priorizados, e se pergunta qual dessas técnicas poderá te levar ao melhor resultado? A essa altura do campeonato eu imagino que você já saiba a resposta: Depende!

Cada método tem suas características e abordagens, por isso é importante saber o que é mais relevante para o seu contexto. Por exemplo, se seu foco estiver no custo, utilize métodos em que este critério tem maior relevância.

Um ponto importante sobre todos os métodos é que se você não der significados claros para os valores das escalas de avaliação, você poderá ter a precisão prejudicada pelo viés e interpretação pessoal.

Já que a melhor técnica não existe, eu compartilharei com você como escolhi e apliquei algumas dessas técnicas para organizar meu backlog.

Como limpei e organizei o backlog do meu produto que já passava dos 700 itens?

O primeiro passo foi respirar fundo, pois eu sabia que o processo não seria algo muito divertido e prazeroso, embora eu deva admitir que, conforme eu via a "casa" ficando em ordem, eu já conseguia sentir o prazer da realização.

O próximo passo foi revisar as técnicas com o objetivo de escolher o método que eu aplicaria.

• Os métodos Valor X Risco e Valor x Custo não me davam a clareza dos diferentes tipos de valores que gostaríamos de ter.
• O Método de Testes de Suposição não nos atendia porque ainda não tínhamos processos bem definidos para validação de hipóteses.
• O Método Scorecard me atraía bastante pelas várias perspectivas de análise, mas percebi que poderia ser muito custoso aplicá-lo no dia a dia.
• O Método BUC me fornecia uma variedade interessante de perspectivas de análise, porém com menos complexidade que o Scorecard.
• O Método MoSCoW era uma forma interessante de agrupar os itens, mas parecia mais uma categorização do que priorização.

Eu decidi seguir com o BUC, mas ainda existiam 2 desafios:

• O volume de itens era muito grande, por isso seria praticamente impossível avaliar de forma consistente a prioridade de todos.
• Era preciso definir critérios claros para agrupá-los e avaliá-los.

Me lembrei do MoSCoW e decidi utilizar as suas técnicas para fazer uma triagem dos itens antes de priorizá-los de fato. Criei então os 4 grupos “Must-Haves, Should-Haves, Can-Haves e Won’t-Haves”, e adicionei um quinto grupo para alocar os itens que seriam descartados. Durante essa primeira triagem não me preocupei muito com a precisão e optei pela velocidade.

Fiquei pensando em nomear essa técnica de MoSCoWD, o que você acha? Me conta nos comentários.

Esse foi o resultado depois de aplicar o MoSCoW — repare que 613 itens foram literalmente descartados:

Parti então para a aplicação dos critérios de avaliação para os 4 grupos.

Certamente você já participou de reuniões com muitas pessoas nas quais discutiu-se prioridade de tarefas. Você já percebeu que nem sempre os envolvidos tem o mesmo entendimento quanto ao critérios de avaliação? Nem sempre prioridade alta é de fato alta para todo mundo. Nestes momentos é necessário equalizar os envolvidos quanto a definição de escala destes critérios.

Logo abaixo eu vou deixar algumas dicas para você conseguir atingir este objetivo, inclusive eu vou te mostrar como eu apliquei essa dica.

1 Defina o significado das extremidades. Qual será o maior e o menor valor, e o que cada um deles significa?

Para o critério de Valor para o Usuário, utilizei o menor valor como 0, e a definição dele é “Não tem valor para o usuário”. Um exemplo dessa atividade poderia ser uma ação que visa diminuir o custo infraestrutura de tecnologia.

Utilizei o maior valor como 4, e a definição dele é “Melhora a experiência em uma atividade primária”. Um exemplo pode ser a construção de alguma funcionalidade que ajude o cliente a realizar o pagamento no checkout do e-commerce.

2 Defina o significado do ponto intermediário

Ainda seguindo no critério de Valor para o Usuário, considerando que o menor valor é 0 e o maior é 4, o ponto intermediário é o valor 2, a definição dele é “Melhora a experiência em uma atividade frequente”. Um exemplo pode ser a construção de uma funcionalidade que facilite a configuração de produtos que estarão disponíveis no e-commerce.

3 Defina o significado das lacunas

Neste ponto já demos significados para 0, 2 e 4 na escala do critério de Valor para o Usuário, ainda falta para os valores 1 e 3, que ficaram definidos respectivamente como “Melhora a experiência em atividade pontual” e “Melhora a experiência em uma atividade secundária”.

Agora o que antes eram números abstratos passaram a ter um significado compartilhado entre todos do time.

Ao tentar definir os significados da escala para o critério de custo eu tive maior dificuldade. O problema é que “custo” é constituído por muitos fatores, dificultando a definição de significados claros para a escala deste critério de avaliação. Após alguma reflexão, eu percebi que a complexidade técnica já refletia alguns dos principais fatores do custo, por exemplo, os custos de equipe e tempo de desenvolvimento.

Sendo assim, optei por utilizar o critério Complexidade técnica em vez de Custo e a escala ficou definida com os seguintes significados:

0 — Pode ser feito por alguém do nosso time em poucos minutos

1 — Pode ser feito por alguém do nosso time, em pouco tempo

2 — Pode ser feito por alguém do nosso time, mas precisa de tempo/foco

3 — Pode ser feito pelo nosso time (+ de 1 pessoa), em pouco tempo

4 — Pode ser feito pelo nosso time (+ de 1 pessoa), mas precisa de tempo/foco

Nesta etapa eu já havia conseguido limpar o backlog do produto, agrupá-lo de forma simples utilizando os princípios do Método MoSCoW, definido critérios de avaliação relevantes com base no BUC e construído uma escala com significados concretos e bem próximos da realidade do time.

Finalmente chegou a hora de avaliar o resultado. Qual foi o método que utilizei?

Para avaliar cada tarefa utilizei a fórmula abaixo:

Benefício para o Usuário + Benefício para o Negócio - Complexidade Técnica = Prioridade

E foi assim que eu revisei a prioridade do nosso backlog do e-commerce. Ao invés de seguir um único método como verdade absoluta, eu utilizei um conjunto de características de métodos distintos.

Quais foram os principais aprendizados da minha jornada?

• Não tem uma fórmula mágica ou método perfeito. É importante conhecer os métodos existentes, assim como entender o seu contexto e objetivos. A partir disso avalie de quais métodos você pode tirar mais benefícios para o cenário em que você está inserido.
• A adaptação do Método MoSCoW nos ajudou a identificar quais itens do backlog do produto seriam descartados, e facilitou a análise de prioridade sob os itens mais importantes.
• Os princípios do Método BUC nos ajudaram a identificar os critérios de avaliação mais relevantes.
• A escolha de critérios de avaliação relevantes e a construção de uma escala de valor com significados bem definidos e alinhados à realidade do time, reduzem a subjetividade das avaliações de prioridade, resultando em mais clareza e menos discussões abstratas.

Deixo então algumas dicas finais

• Antes de escolher um método reflita sobre seu objetivo, foco e critérios de avaliação mais relevantes.
• Sempre que possível, evite avaliar e priorizar sozinho. Se não puder reunir todas as partes interessadas ao mesmo tempo, consulte diretamente os especialistas para validar sua percepção. Por exemplo, consulte os desenvolvedores sobre os riscos e complexidade técnica, valide com os stakeholders o valor de negócio, etc.
• Defina significados claros para os valores das escalas e compartilhe com as pessoas.
• Não faça como eu, não demore tanto para organizar seu backlog, ele deve sempre ser transparente, visível e compreensível.