Priorizando Itens do Backlog Efetivamente

Priorização de backlog é onde estratégia encontra execução. Sem priorização clara, times trabalham no que é mais novo ou mais barulhento ao invés do que é mais valioso. Priorização efetiva usa frameworks, dados e input de stakeholders para garantir que cada sprint entregue máximo impacto.

Desafios de Priorização

Frameworks de Priorização

Framework RICE

MÉTODO DE PONTUAÇÃO RICE
════════════════════════

FÓRMULA:
Score RICE = (Reach × Impact × Confidence) / Effort

COMPONENTES:
─────────────────────────────────────
REACH: Quantos usuários afetados por trimestre?
├── 1.000 = 1.000 usuários
├── 10.000 = 10K usuários
└── Use números reais

IMPACT: Quanto ajuda cada usuário?
├── 3 = Massivo (melhoria enorme)
├── 2 = Alto (melhoria major)
├── 1 = Médio (melhoria notável)
├── 0.5 = Baixo (melhoria menor)
└── 0.25 = Mínimo (quase imperceptível)

CONFIDENCE: Quão certo você está?
├── 100% = Alta confiança
├── 80% = Média confiança
├── 50% = Baixa confiança
└── Use avaliação honesta

EFFORT: Pessoa-meses de trabalho
├── 1 = 1 pessoa-mês
├── 0.5 = 2 semanas
└── Números inteiros preferidos

EXEMPLO:
─────────────────────────────────────
Feature: Busca melhorada

Reach: 50.000 usuários/trimestre
Impact: 2 (alto)
Confidence: 80%
Effort: 2 pessoa-meses

RICE = (50.000 × 2 × 0.8) / 2 = 40.000

Compare com scores RICE de outras features
Maior = maior prioridade

Método MoSCoW

CATEGORIZAÇÃO MOSCOW
════════════════════

CATEGORIAS:
─────────────────────────────────────
MUST HAVE (DEVE TER):
├── Essencial para release
├── Produto falha sem isso
├── Não-negociável
└── ~60% do esforço

SHOULD HAVE (DEVERIA TER):
├── Importante mas não vital
├── Doloroso omitir
├── Workaround possível
└── ~20% do esforço

COULD HAVE (PODERIA TER):
├── Nice to have
├── Quick wins incluídos
├── Primeiro a cortar se necessário
└── ~20% do esforço

WON'T HAVE (NÃO TERÁ desta vez):
├── Desejos reconhecidos
├── Explicitamente fora de escopo
├── Consideração futura
└── Documentado, não esquecido

EXEMPLO DE SPRINT:
─────────────────────────────────────
MUST:
├── Login de usuário
├── Reset de senha
└── Criação de perfil

SHOULD:
├── Integração OAuth
├── Opção lembrar de mim

COULD:
├── Upload de avatar
├── Autenticação dois fatores

WON'T:
├── Login social
├── Autenticação biométrica

SE ATRASANDO:
├── Mantenha todos MUST
├── Avalie itens SHOULD
├── Corte itens COULD primeiro
└── Nunca corte MUST

Matriz Valor vs Esforço

MATRIZ VALOR VS ESFORÇO
═══════════════════════

                  BAIXO ESFORÇO     ALTO ESFORÇO
             ┌──────────────────┬──────────────────┐
             │                  │                  │
   ALTO      │   QUICK WINS     │   BIG BETS       │
   VALOR     │   Faça primeiro! │   Planeje bem    │
             │   ★★★★★          │   ★★★★☆          │
             │                  │                  │
             ├──────────────────┼──────────────────┤
             │                  │                  │
   BAIXO     │   PREENCHEDORES  │   EVITE          │
   VALOR     │   Faça se sobrar │   Não faça       │
             │   ★★☆☆☆          │   ★☆☆☆☆          │
             │                  │                  │
             └──────────────────┴──────────────────┘

ORDEM DE PRIORIDADE:
─────────────────────────────────────
1. QUICK WINS: Alto valor, baixo esforço
   Comece aqui. Máximo ROI.

2. BIG BETS: Alto valor, alto esforço
   Vale a pena, mas planeje bem.

3. PREENCHEDORES: Baixo valor, baixo esforço
   Use para preencher gaps. Não priorize.

4. EVITE: Baixo valor, alto esforço
   Por que você faria? Não faça.

POSICIONAMENTO VISUAL:
─────────────────────────────────────
Mapeie cada item do backlog na matriz.
Visualização clara ajuda discussões.
"Por que estamos fazendo esse item de baixo valor
quando esses quick wins estão esperando?"

Processo

Priorização Regular

PROCESSO DE PRIORIZAÇÃO
═══════════════════════

REFINAMENTO SEMANAL DO BACKLOG:
─────────────────────────────────────
1. REVISAR NOVOS ITENS (15 min)
   ├── Alguma nova requisição essa semana?
   ├── Avaliação inicial de valor
   ├── Estimativa rough de esforço
   └── Adicionar ao backlog na posição certa

2. PONTUAR TOP ITENS (20 min)
   ├── Aplicar RICE aos top 20 itens
   ├── Atualizar se nova informação
   ├── Discutir desacordos de pontuação
   └── Rankear por score

3. VALIDAR COM STAKEHOLDERS (15 min)
   ├── Ranking corresponde a expectativas?
   ├── Alguma mudança estratégica?
   ├── Contexto faltando?
   └── Ajustes finais

4. PREPARAR PARA SPRINT (10 min)
   ├── Top itens estão prontos para sprint?
   ├── Critérios de aceite claros?
   ├── Dimensionados apropriadamente?
   └── Dependências identificadas?

OUTPUT:
─────────────────────────────────────
├── Backlog priorizado
├── Top itens prontos para sprint
├── Alinhamento de stakeholders
└── Decisões documentadas

Lidando com Conflitos

RESOLVENDO CONFLITOS DE PRIORIDADE
══════════════════════════════════

CONFLITOS COMUNS:
─────────────────────────────────────
├── Stakeholder A quer Feature X
├── Stakeholder B quer Feature Y
├── Ambos alegam "maior prioridade"
└── Capacidade limitada

FRAMEWORK DE RESOLUÇÃO:
─────────────────────────────────────
Passo 1: Use dados
├── O que os scores RICE dizem?
├── Qual tem maior valor?
├── Qual tem melhor ROI?
└── Dados frequentemente resolvem conflito

Passo 2: Conecte à estratégia
├── Qual a prioridade da empresa?
├── Qual alinha com objetivos?
├── CEO como desempate?
└── Estratégia fornece direção

Passo 3: Facilite discussão
├── Traga stakeholders juntos
├── Compartilhe dados transparentemente
├── Deixe-os ouvir um ao outro
└── Frequentemente encontram compromisso

Passo 4: Product Owner decide
├── Quando consenso impossível
├── PO tem autoridade final
├── Decisão é documentada
├── Seguir em frente
└── Revisar se contexto mudar

DOCUMENTAÇÃO:
─────────────────────────────────────
"Decisão: Feature X priorizada sobre Y porque:
- Score RICE mais alto (45K vs 32K)
- Alinha com metas de receita do Q1
- Menor risco, maior confiança
Feature Y planejada para próximo trimestre."

Setup GitScrum

Gestão de Prioridades

PRIORIZAÇÃO NO GITSCRUM
═══════════════════════

CAMPO DE PRIORIDADE:
─────────────────────────────────────
Cada item tem prioridade:
├── P0 - Crítico (bloqueia outro trabalho)
├── P1 - Alto (funcionalidade core)
├── P2 - Médio (importante)
├── P3 - Baixo (nice to have)
└── Usado para filtragem rápida

CAMPOS CUSTOM PARA RICE:
─────────────────────────────────────
Adicione campos:
├── Reach (número)
├── Impact (select: 0.25, 0.5, 1, 2, 3)
├── Confidence (select: 50%, 80%, 100%)
├── Effort (número)
├── RICE Score (calculado)
└── Ordene por RICE decrescente

VISUALIZAÇÃO DO BACKLOG:
─────────────────────────────────────
View: Backlog Priorizado
Ordenar por: RICE Score (desc)
Agrupar por: Nível de prioridade
Mostrar: Título, RICE, Assignee, Status

LABELS:
─────────────────────────────────────
├── must-have (vermelho)
├── should-have (amarelo)
├── could-have (verde)
├── wont-have (cinza)
└── Filtragem MoSCoW rápida

Melhores Práticas

Para Priorização

1. Use um framework — Critérios consistentes
2. Pontue tudo — Torne valor visível
3. Cadência regular — Refinamento semanal
4. Dono único — Product Owner decide
5. Documente decisões — Previna re-discussão

Anti-Padrões

ERROS DE PRIORIZAÇÃO:
✗ Tudo é P1
✗ Mais novo = maior prioridade
✗ Stakeholder mais barulhento vence
✗ Sem framework, só feeling
✗ Nunca dizer "não" ou "depois"
✗ Repriorizar no meio do sprint
✗ Ignorar dados por política
✗ Não comunicar prioridades

Soluções Relacionadas

• Criando sprint backlogs efetivos
• Melhores práticas de grooming de backlog
• Gestão de requisições de features de clientes