Pontuação RICE: fórmula, exemplo prático e armadilhas

A pontuação RICE ordena ideias de produto com um único número: alcance vezes impacto vezes confiança, dividido pelo esforço. Uma pontuação maior significa mais valor esperado por unidade de trabalho. O método nasceu no time de produto da Intercom e virou uma forma padrão de comparar pedidos de funcionalidades que a intuição não consegue separar. Funciona melhor em uma lista curta de candidatos sérios, e só é tão bom quanto as estimativas que entram nele.

Qual é a fórmula da pontuação RICE?

A pontuação é Alcance × Impacto × Confiança ÷ Esforço. Alcance, impacto e confiança se multiplicam porque cada um escala o retorno, e o esforço divide porque o mesmo retorno custa mais quando exige mais trabalho. Escolha uma única janela de tempo para o alcance, como um trimestre, e use a mesma em todos os itens, ou as pontuações não serão comparáveis.

O texto original da Intercom define as escalas da tabela acima, e a maioria das equipes as mantém sem alterações para que as pontuações continuem comparáveis entre pessoas.

Como pontuar cada fator do RICE?

O alcance vem de dados que você já tem. Para um pedido de funcionalidade, comece pelo número de contas distintas que pediram e some uma estimativa das contas que a usariam sem pedir. O impacto é o fator menos preciso, então use a escala de cinco valores e resista a inventar decimais. A confiança é um desconto por chute: use 100% só quando tiver dados de uso ou um protótipo testado, 80% quando tiver sinais fortes e 50% quando estiver basicamente chutando. O esforço é o tempo de todos os envolvidos, design e testes incluídos, em pessoa-mês.

Duas pessoas pontuando o mesmo item devem ficar a no máximo um degrau de distância em cada fator. Se não ficarem, o item não está entendido o bastante para ser ordenado, e a discordância é o achado.

Como é um exemplo de pontuação RICE?

Pegue quatro pedidos de um backlog rastreado, pontuados para um trimestre.

Resolva a primeira linha: 400 × 1 × 0,8 ÷ 1 = 320. O modo escuro alcança três vezes mais pessoas, mas cada uma ganha pouco, então fica logo abaixo da exportação. A integração com o Slack tem uma boa nota de impacto que a confiança corta pela metade, o que indica que o próximo passo é pesquisar, não construir.

O single sign-on fica em último, e isso merece uma segunda olhada. Sessenta contas é um alcance pequeno, mas se forem as contas maiores e várias renovações dependerem da funcionalidade, a pontuação deixa de fora algo que o método não enxerga.

Quais são os erros mais comuns do RICE?

O primeiro é a falsa precisão. Um alcance de 1.247 e um impacto de 1,3 parecem rigorosos e não trazem mais informação que 1.200 e 1. Arredonde sem medo.

O segundo é pontuar itens que você já decidiu construir. As notas então são ajustadas até o favorito vencer, e o exercício só serve de álibi.

O terceiro é ignorar quem pediu. O RICE conta pessoas, então o pedido de dez contas pequenas supera o pedido de uma conta que vale mais que as dez juntas. Quando a receita importa, adicione uma coluna para ela e leia-a ao lado da pontuação. A ponderação por conta está em como priorizar pedidos de funcionalidades.

O quarto é comparar pontuações de janelas de tempo diferentes ou de escalas de times diferentes. Mantenha uma planilha, uma janela e um conjunto de definições.

Quando usar algo diferente do RICE?

Quando você não tem dados de alcance, use o ICE (impacto, confiança, facilidade), que elimina o alcance e troca o esforço por uma nota de facilidade, aceitando que é mais grosseiro. Quando a pergunta é que tipo de valor uma funcionalidade carrega, e não quanto, o modelo Kano classifica os pedidos como funcionalidades obrigatórias, de desempenho ou de encantamento, e os dois combinam bem. Quando a decisão é sobre ordem e momento, e não sobre ranking, um formato de roadmap serve melhor, e como criar um roadmap de produto trata disso.

Como manter as pontuações RICE honestas ao longo do tempo?

Guarde os dados de entrada junto da pontuação, e não só o resultado, para que qualquer pessoa veja qual premissa puxou uma posição. Revise um item quando os fatos dele mudarem, como um novo lote de pedidos elevando o alcance ou um engenheiro percebendo que o esforço dobrou. Depois do lançamento, compare o alcance e o impacto previstos com o que aconteceu e ajuste a forma como seu time estima da próxima vez. A matéria-prima do alcance é a lista agrupada e etiquetada de pedidos descrita em rastreamento de pedidos de funcionalidades, e o resultado pertence à resposta que você envia a quem pediu.

FAQ

O que é uma boa pontuação RICE? Não existe um limite universal, porque o número depende da sua janela de alcance e da unidade de esforço. Compare pontuações apenas dentro de uma mesma planilha e trate o ranking, e não o valor absoluto, como o resultado.

Qual é a diferença entre a pontuação RICE e a ICE? O ICE multiplica impacto, confiança e facilidade e deixa o alcance de fora. É mais rápido de preencher e menos preciso quando as funcionalidades afetam números muito diferentes de usuários, que é o caso para o qual o RICE foi criado.

Como estimar o alcance de um pedido de funcionalidade? Comece pela contagem de contas que pediram, some a parcela de contas ativas que provavelmente a usariam sem ser lembrada e expresse o total por trimestre. Se o palpite for grosseiro, reduza o fator de confiança em vez de inventar precisão.

Todo pedido de funcionalidade deve ser pontuado com o RICE? Não. Pontuar vale o esforço para o punhado de itens próximos o bastante para precisar de um desempate. Vitórias óbvias e rejeições óbvias podem ser decididas sem isso.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Comparativo de ferramentas de changelog