Priorização de Backlog: como ser mais produtivo na definição do escopo de um produto

Certa vez, um professor me intrigou com sua frase “Com R$1 na mão, o chiclete é concorrente do pão.” Sua colocação me abriu a cabeça para um detalhe: geralmente, partimos da premissa de que nossas decisões são feitas com base em opções similares. Desenvolver a integração para autenticar usando Facebook ou Google versus uma autenticação em dois fatores? Cappuccino ou média com leite? Mas, quando temos recursos limitados, o que espero só aconteça comigo, o buraco é mais embaixo. Eu precisei usar algumas técnicas para não me dar mal com isso. Vou compartilhar meu aprendizado sobre elas neste artigo.

Brincadeiras à parte, a restrição de recursos é uma realidade para qualquer product owner (PO). Sejam pessoas, tempo, ferramentas de trabalho, informações ou qualquer outra variável, uma das habilidades mais “ninja” do PO é priorizar seu backlog. Isso porque você é bombardeado (e se não for, sinal amarelo deveria estar aceso) por necessidades, desejos, demandas e o que mais vier de várias frentes: clientes, vendas, marketing, suporte técnico, customer success, squad, C-level. Muita gente, com diferentes realidades e interesses, pedindo muita coisa bem diferente uma da outra. Isso torna a priorização uma questão complexa de se resolver e, por isso, convém basear nossa decisão na aplicação de alguma técnica que minimize o risco da subjetividade.

Neste artigo, vou analisar algumas técnicas conhecidas de priorização, como o MoSCoW, o Modelo de Kano e o Método da Votação Cumulativa. Apresento também uma alternativa que pode ajudar você a expandir sua visão sobre a priorização, dar um modelo mental que colabora na sua negociação com os stakeholders e busca pacificar o processo de tomada de decisão sobre a definição do escopo de um produto.

MoSCoW: Fácil de usar e um tanto Subjetivo

É uma das técnicas mais conhecidas e utilizadas. O legal é que seu nome já é uma “cola” para lembrar do conceito e dos parâmetros que a constituem. Tem o cacife de algumas organizações de peso, dada a recomendação feita à analistas de negócio no IIBA BABOK (International Institute of Business Analysis — Business Analysis Body of Knowledge), além de ter sua origem no DSDM (Dynamic Software Development Method). O MoSCoW se baseia em 4 categorias que tratam diretamente sobre o nível de importância dos itens a priorizar:

• [M]ust Have: Serve para os itens que devem ser entregues no produto para que ele seja considerado bem-sucedido. A dica para saber se algum item cai nessa categoria é avaliar se a release precisaria ser cancelada caso o requisito não estiver incluso. Obrigatoriamente, devem estar presentes no MVP (mínimo produto viável). Por exemplo: o registro da realização de uma transação bancária em um sistema de gestão financeira.
• [S]hould Have: Indicado para itens que são altamente desejáveis, mas não obrigatórios. São itens críticos, mas que é possível sobreviver sem eles caso necessário. Trazem impacto na experiência do cliente, mas não impedem o uso do produto. Por exemplo: “esqueci minha senha”.
• [C]ould Have: Esta categoria é para os itens que são desejáveis mas não obrigatórios. Se os recursos forem muito escassos, provavelmente nunca serão priorizados. Porém, podem ser itens que tragam um diferencial na experiência do usuário e podem resultar em ótimas surpresas no seu engajamento. Para quem conhece o Slack, ao meu ver o onboarding do usuário através do Slackbot se encaixa aqui.
• [W]on´t Have: Essa categoria dá até pena. Aqui entram os itens que todos acham que podem ser entregues quando der (muitas vezes, isso significa nunca). Por exemplo: uma alteração no estilo de um relatório que poucos usuários precisam.

Particularmente, gosto do MoSCoW pela sua facilidade de uso. Eu costumo utilizá-lo quando existem poucos stakeholders e a comunicação com eles é fácil. Isso porque ele tem uma parcela significativa de subjetividade, escondendo os motivos que justificam uma ou outra classificação. Obviamente, quanto mais o cliente participar do processo de classificação, melhor será o resultado. Caso queira aplicar essa técnica no planejamento das releases, uma dica é iterar na priorização a cada definição. Para ser mais claro: classificar todas as histórias e colocar todas as [M] na primeira release (necessário avaliar também se e quando o time tem capacidade para entregar todas — mas isso é assunto para outro artigo). Com as histórias que sobraram, reaplicar a classificação. Como se o cliente pensasse “como o produto já tem isso, agora esse requisito, que antes não era obrigatório, passa a ser fundamental para mim”. Isto é, alguns requisitos [S] passarão a ser [M] e por aí vai.

Modelo de Kano: Intrincado e Detalhista

Noriaki Kano é um dos papas do movimento de gestão da qualidade total, semeado no Japão pós-guerra por especialistas americanos (Deming principalmente) e aprimorado pelos japoneses.

Dentro do Modelo de Kano, as funcionalidades são categorizadas em cinco níveis, de acordo com as necessidades e expectativas dos clientes quanto à sua presença e desempenho: obrigatórias, atrativas, unidimensionais, neutras/indiferentes e reversas. Note que essa as categorias estão em ordem de prioridade:

• Obrigatórias: Atendem necessidades básicas do cliente e sua expectativa é que esses requisitos estejam no produto e não trarão satisfação por estarem. Porém caso não estejam, a insatisfação é certa. Por exemplo: a possibilidade de alterar os itens de um carrinho de compras.
• Unidimensionais: Caso esteja presente, gera satisfação. Caso ausente, gera insatisfação. São histórias que podem trazer diferenciação e vantagem competitiva ao produto. Por exemplo: um mecanismo de busca com indexação não estruturada de dados de itens de um catálogo.
• Atrativas: São itens até difíceis de se identificar junto aos clientes, já que não são esperados no produto. Isto é, podem surpreender positivamente quando presentes, mas não geram insatisfação se faltarem. Um caso que cairia nessa categoria seria um mecanismo de recomendação de alternativas, com base na similaridade de função ou forma.
• Neutras/Indiferentes: Aqui entram itens que não fedem e não cheiram, que não geram satisfação ou insatisfação. Por exemplo: a paralelização de servidores para serviços pouco exigidos.
• Reversas: São aquelas que o tiro sai pela culatra. Caso existam, causam insatisfação. Por exemplo: um cadastro enorme numa mesma página com vários campos obrigatórios que devem ser preenchidos de uma vez.

Para quem é mais visual, essas categorias foram representadas no chamado Diagrama de Kano:

Figura 1: Diagrama de Kano (fonte: https://www.researchgate.net/figure/Figura-1-Modelo-de-Kano-de-qualidade-atrativa-Fonte-adaptado-de-Loefgren-e-Witell-2005_fig1_307782990)

Você deve ter percebido que existe uma relação entre o MoSCoW e Kano. Considero Kano mais difícil de explicar para um cliente e fazê-lo usar. Minha sugestão é que seja usado para análises detalhadas de alguma funcionalidade. Acredito que fique mais claro com o exemplo a seguir:

Funcionalidade: Notificar usuário quando status do pedido é alterado

Pergunta 1 (funcional/positiva): Como você se sente quando é notificado que o status do seu pedido foi alterado?

Pergunta 2 (disfuncional/negativa): Como você se sente quando NÃO é notificado que o status do seu pedido foi alterado?

Opções de resposta para as duas perguntas:

• Eu gosto disso
• Eu espero isso
• Eu sou neutro em relação a isso
• Eu tolero isso
• Eu não gosto disso

Assim, se as respostas da pergunta 1 tenderem para “eu gosto disso” e da pergunta 2 para “eu não gosto disso”, essa funcionalidade seria classificada como “unidimensional”.

Método da Votação Cumulativa: Lúdico e Fácil

Assim como o MoSCoW, esse método é mais simples de ser aplicado. Consiste em pedir para cada stakeholder distribuir uma determinada quantidade de pontos pelos itens a serem priorizados. Caso um stakeholder tenha 100 pontos para distribuir e considere o item mega-prioritário, pode colocar todos os 100 pontos nesse item. É uma técnica muito lúdica e mimetiza bem a necessidade de priorização com base em recursos limitados. Gosto dela para cenários onde existem percepções muito diversas entre os stakeholders e uma busca por consenso ou convencimento da maioria seria muito demorada ou custosa.

Modelo baseado na Maximização do Valor: Abrangente e Balanceado

Esse último modelo é mais recomendado para priorizações com muitos stakeholders com diferentes opiniões, onde é importante considerar e oficializar as possíveis motivações.

Esse modelo proposto utiliza os conceitos apresentados por Rebecca Henderson (MIT) com base na análise do valor que o item possui, sob três pontos de vista:

• Geração de Valor: busca definir o quanto o item em questão gera de valor para o cliente/usuário, podendo ser expresso em termos do potencial de aumento na sua satisfação com o produto desenvolvido. No caso de stakeholders C-level, a geração de valor geralmente se dá por meio do potencial de aumento de receita, redução de despesas ou melhoria na imagem;
• Captação de Valor: busca definir o potencial de retorno que a empresa obterá com o desenvolvimento do item, geralmente com base em alguma métrica transacional ou de atividade do usuário;
• Capacidade de Fornecimento de Valor: busca estabelecer o domínio tecnológico que a empresa possui para garantir o fornecimento do item dentro das suas especificações.

Sugiro que esses pontos de vista sejam debatidos e desdobrados na empresa. Para a sua aplicação, pode-se utilizar uma ficha de avaliação, como a do exemplo abaixo:

Figura 2: Ficha de Avaliação (fonte: https://repositorio.ufsc.br/xmlui/bitstream/handle/123456789/82404/190476.pdf?sequence=1&isAllowed=y)

Gosto desse modelo já que busca entender o contexto de uma forma mais abrangente e de forma a balancear os interesses dos diversos stakeholders. Cada um deles pode dar notas para os critérios e a média geral, ponderada ou não, indica qual a prioridade do item.

Não Existe a Melhor Solução

Apresentei e analisei quatro opções diferentes para que você possa fazer uma melhor priorização do seu backlog junto a seus stakeholders e squad e, com isso, criar um produto que atenda a expectativa de todos os envolvidos.

Claramente, as quatro soluções têm pontos fortes e fracos, e podem ser aplicadas em conjunto de forma complementar. Com certeza não todas no mesmo projeto, mas a utilização de um par delas pode ser uma boa alternativa para se ter uma priorização mais simples de entender e aplicar (MoSCoW, Votação Cumulativa) e um detalhamento em alguns momentos do projeto, com uso de técnicas mais robustas (Kano, Maximização de Valor).

E quanto a você, como prioriza seu backlog? Compartilhe sua experiência!