Segunda-feira de manhã, 9h15. Três gerentes de projeto me enviam mensagem ao mesmo tempo. O cliente A quer o protótipo até quinta. O cliente B tem 'só uma pequena mudança' (spoiler: nunca é pequena). O cliente C ameaça não assinar a próxima fase se não entregarmos a funcionalidade prometida há seis semanas. E o backlog tem 74 tickets que ninguém tocou desde o último sprint planning. Esta é a realidade de 90% das agências digitais. Não a teoria Agile limpa dos eventos.
Por Que Seu Backlog Parece um Lixão
O problema não é o volume de trabalho. É a ausência de um critério de priorização compartilhado. Cada PM defende seu projeto, cada cliente grita urgência, e o lead dev navega pelo que está sangrando mais. Tarefas de alto impacto sem prazo imediato afundam no fundo do backlog. Para sempre.
Métodos Que Realmente Funcionam
MoSCoW: Simples, Mas Quase Sempre Mal Aplicado
Must have, Should have, Could have, Won't have. Todo mundo conhece. Quase ninguém aplica certo. A armadilha clássica: clientes colocam tudo em Must have porque não entendem que isso compromete sua capacidade de sprint. A correção: validar o MoSCoW com um orçamento de pontos. Você tem 40 pontos por sprint. Cada Must have custa pontos. O cliente arbitra quando o orçamento acaba. Isso muda completamente a dinâmica.
RICE: O Framework Que Gostaria de Ter Conhecido Antes
RICE é Reach x Impact x Confidence / Effort. Uma pontuação numérica por ticket. Parece frio, mas elimina debates de ego nas reuniões. Você não precisa mais convencer o fundador de que a feature 'genial' dele é um Could have. A pontuação decide. Vi uma equipe reduzir o sprint planning de 2,5 horas para 45 minutos em três sprints após adotar o RICE.
Paramos de brigar nas reuniões no dia em que decidimos que quem mandava era o score RICE, não quem falava mais alto. Nosso burn rate caiu 22% em dois meses. -- Diretor de Produção, agência e-commerce, Lyon, 2025.
Capacidade Real: O Número Que Ninguém Calcula
Agências planejam com capacidade teórica. 5 devs x 5 dias x 8h = 200 horas de sprint. Na prática, após standups, revisões de código e chamadas não planejadas, você tem entre 120 e 140 horas produtivas. De 30 a 40% de perda líquida. Calcular a velocidade real em seis sprints consecutivos é inegociável. Ferramentas como o Clynt permitem cruzar as horas registradas por projeto com a capacidade planejada, dando uma leitura honesta da diferença.
Priorizar Entre Projetos: O Desafio Real das Agências Multi-cliente
Se a resposta para 'quem decide?' é 'quem liga mais', você tem um problema de governança, não de metodologia. Uma regra prática que funciona: pesar por margem bruta x risco de churn. Projetos de baixa margem com clientes voláteis descem na fila. Contas estratégicas de alta margem sobem. Incomoda no começo. Mas alinha as decisões operacionais com a estratégia real da agência.
- Calcular a margem bruta por projeto semanalmente, não trimestralmente
- Atribuir um score de risco de churn (1-5) a cada conta de cliente ativa
- Multiplicar ambos para obter um índice de prioridade entre projetos
- Revisar esse índice em comitê de direção a cada duas semanas
FAQ
Qual método de priorização é melhor para agências pequenas com menos de 10 pessoas?
MoSCoW com orçamento de pontos é o mais acessível para times pequenos. Não exige nenhuma ferramenta específica e funciona em um Notion simples ou planilha. O essencial é definir as regras com o cliente desde o kick-off, não no meio do projeto.
Como convencer um cliente de que o pedido urgente dele não é prioridade?
Mostre o backlog priorizado com impactos de negócio quantificados. Um cliente racional entende que uma feature que afeta 3 usuários espera depois de uma correção que impacta 800 pedidos diários. Se o contrato prevê SLAs claros por nível de urgência, fica ainda mais simples.
O backlog interno da agência precisa ser separado do backlog do cliente?
Sim, sem hesitação. Misturar os dois cria uma hierarquia implícita onde o trabalho do cliente sempre ganha. Suas tarefas de melhoria interna nunca terão espaço se competirem diretamente com urgências do cliente. Dois espaços distintos, dois rituais distintos.
Como medir a velocidade real de uma equipe em uma agência com múltiplos projetos?
Cruze as horas efetivamente registradas nos tickets entregues com a capacidade planejada em seis sprints consecutivos. O Clynt permite visualizar essa diferença por projeto e por perfil, possibilitando compromissos futuros com base em dados reais e não em intuições.