Priorização MoSCoW

Resposta rápida: a Priorização MoSCoW é um método para classificar o que entra (ou não) num projeto em quatro grupos: Must have (essencial), Should have (importante), Could have (desejável) e Won't have this time (fica de fora desta vez). Foi criada por Dai Clegg, da Oracle, em 1994. Em vez de tratar tudo como urgente, ela separa o indispensável do supérfluo e protege o prazo.

O que é a Priorização MoSCoW?#

A Priorização MoSCoW é uma técnica de priorização de requisitos que organiza tudo o que um time poderia fazer em quatro categorias de importância. A ideia central é simples e poderosa: nem toda tarefa tem o mesmo peso, e fingir que tem é a receita para estourar prazo. O método força uma conversa honesta sobre o que é, de fato, indispensável para a entrega.

O nome é um acrônimo formado pelas iniciais das quatro categorias em inglês — Must have, Should have, Could have e Won't have. Os dois "o" minúsculos foram inseridos só para tornar a palavra pronunciável (MoSCoW, lida como a cidade "Moscou", em inglês). Eles não significam nada — por isso aparecem em caixa baixa, para deixar claro que não fazem parte da sigla. Quem criou o método optou por essa grafia justamente para que ninguém confundisse os "o" com uma quinta ou sexta categoria.

A grande virada de pensamento da MoSCoW é trocar a pergunta "isto é importante?" (à qual quase tudo responde "sim") pela pergunta "o que acontece com a entrega se isto NÃO for feito?". Essa mudança de enquadramento expõe a verdade: muito do que parecia obrigatório é, na prática, negociável. E é nessa margem de negociação que mora a capacidade de entregar no prazo.

Para que serve a Priorização MoSCoW?#

A MoSCoW serve para chegar a um acordo claro entre todos os envolvidos sobre a importância de cada requisito — e, com isso, garantir que o essencial seja entregue mesmo quando o tempo ou o dinheiro apertam. Ela é especialmente útil em entregas com prazo fixo, onde o escopo precisa flexionar para a data não se mover. Na prática, ela entrega:

• Linguagem comum: "Must" e "Could" significam a mesma coisa para o desenvolvedor, o cliente e o gestor. Acaba a ambiguidade de "alta prioridade".
• Prazo protegido: ao fixar a data e flexibilizar o escopo, o time sempre tem o que cortar (os Coulds) sem comprometer a entrega do que é vital.
• Decisão explícita sobre o que fica de fora: o "Won't have" registra, por escrito, o que foi deixado para depois — evitando que volte como cobrança.
• Conversa sobre valor, não sobre tarefas: a discussão muda de "quanto trabalho dá" para "quanto isso vale para o resultado".

Embora tenha nascido no desenvolvimento de software, a MoSCoW se aplica a praticamente qualquer contexto onde haja mais demanda do que capacidade: planejamento de releases de produto, escopo de projetos, roadmap, definição de um MVP, organização de um backlog e até priorização pessoal de tarefas.

Quando usar: a MoSCoW brilha quando há prazo ou orçamento fixos e escopo negociável — o clássico "precisa ficar pronto para a feira de outubro, custe o que custar em escopo". Ela é a ferramenta para decidir, com o cliente, o que entra no caminhão antes de ele partir.

Quais são as 4 categorias da MoSCoW?#

O coração do método são as quatro categorias. O segredo está em entender que a fronteira decisiva fica entre o Must e o Should: tudo acima dela é inegociável; tudo abaixo é, em algum grau, flexível.

Must have (Tem que ter)#

É o inegociável — o requisito sem o qual a entrega não tem valor, é ilegal, inviável ou inseguro. O teste prático é cru: "se isto não for entregue, faz sentido entregar o resto?". Se a resposta for "não", é Must. Uma forma de lembrar: Must também pode ser lido como Minimum Usable SubseT — o subconjunto mínimo utilizável. Sem todos os Musts, o projeto fracassa.

Should have (Deveria ter)#

É importante, mas não vital. Sua ausência dói, mas não mata a entrega — existe um contorno, mesmo que doloroso ou manual. A diferença para o Must é essa: o sistema ainda funciona sem ele, ainda que de forma menos confortável. Muitos Shoulds são tão relevantes quanto Musts em outro momento; só não são críticos para esta entrega.

Could have (Poderia ter)#

É desejável, mas de impacto bem menor se ficar de fora. São os "bons de ter" que melhoram a experiência, mas que ninguém sentirá falta de imediato. Sua função é estratégica: os Coulds são a reserva de contingência do projeto. Quando algo dá errado e o tempo aperta, são eles — e só eles — que se sacrificam primeiro, protegendo Musts e Shoulds.

Won't have this time (Não terá desta vez)#

É o que o time concorda explicitamente em não fazer agora. A palavra-chave é this time ("desta vez"): não significa "nunca", e sim "não nesta entrega". Categorizar algo como Won't have é uma decisão valiosa — deixa o escopo nítido, evita trabalho disperso e guarda a ideia para um próximo ciclo, sem que ela vire ruído no atual.

Quem criou o método MoSCoW? (Dai Clegg, 1994)#

A Priorização MoSCoW foi criada por Dai Clegg em 1994, quando ele trabalhava na Oracle. Clegg desenvolveu a técnica no contexto do rapid application development (RAD) — o desenvolvimento rápido de aplicações — para ajudar seu time a separar, de forma objetiva, as tarefas críticas das não críticas dentro de prazos curtos e fixos.

A descrição original apareceu no livro Case Method Fast-Track: A RAD Approach, de Dai Clegg e Richard Barker, publicado em 1994. Mas foi a adoção pela comunidade DSDM (Dynamic Systems Development Method) que projetou o método mundialmente. A partir de 2002, a MoSCoW passou a ser usada extensivamente como técnica central do DSDM, e ganhou destaque ainda maior com o lançamento do DSDM Atern, em 2007. Hoje o método é mantido e documentado pelo Agile Business Consortium, sucessor do consórcio DSDM.

O encaixe com o DSDM não foi por acaso. O DSDM parte de um princípio rígido: o prazo e o custo são fixos; o que flexiona é o escopo. Para que essa flexão seja possível sem caos, é preciso saber exatamente o que se pode cortar — e é justamente isso que a MoSCoW entrega. Por isso os dois se tornaram quase inseparáveis na cultura ágil.

"A grafia foi pensada com os 'o' em minúsculo justamente para indicar que eles não representam nada — estão ali só para tornar o acrônimo pronunciável."
— Princípio editorial da técnica, conforme a definição de referência da MoSCoW e a documentação do Agile Business Consortium.

Must vs Should: como diferenciar na prática#

A dúvida que mais trava times é a fronteira entre Must e Should — porque, no calor da reunião, quase tudo "parece" essencial. A MoSCoW oferece um teste decisivo para furar essa percepção inflada: a pergunta da exceção.

Pergunte: "o que faríamos se este requisito não ficasse pronto até a data de entrega?". As respostas separam as águas:

• "Cancelaríamos a entrega" ou "não faria sentido lançar" → é Must.
• "Daríamos um jeito provisório, mesmo que manual e chato" → é Should.
• "Ninguém ia perceber tão cedo" → é Could.

Outro filtro útil é desconfiar de Musts disfarçados. Frases como "o cliente vai querer" ou "é obviamente importante" não bastam — importância não é a mesma coisa que criticidade. Há também o Must condicional: às vezes um requisito só é Must se outro for feito; nesse caso, deixe a dependência explícita. Por fim, vale lembrar a regra de ouro do DSDM: se a lista de Musts está enorme, provavelmente ela está errada. Um projeto saudável tem poucos Musts e uma boa folga de Coulds.

Como aplicar a MoSCoW passo a passo#

Na prática, conduzir uma priorização MoSCoW num projeto segue este roteiro:

1. Liste todos os requisitos no mesmo nível. Reúna o backlog, as funcionalidades ou as tarefas candidatas. Comece com tudo na mesma mesa, sem rótulo, para não ancorar a discussão em julgamentos prévios.
2. Defina o objetivo e o prazo da entrega. "Prioritário em relação a quê?" Sem um objetivo claro e uma data, a classificação vira chute. A MoSCoW pressupõe uma entrega com data fixa.
3. Classifique cada item com a pergunta da exceção. Para cada requisito, aplique o teste: "o que acontece com a entrega se isto não for feito?". Encaixe em Must, Should, Could ou Won't have this time.
4. Aplique a regra de esforço. Some o esforço de cada categoria. Os Musts devem representar, no máximo, cerca de 60% da capacidade da entrega — e mantenha um bom pulmão de Coulds (em torno de 20%) como contingência. Se os Musts passarem de 60%, há risco de não entregar; rebaixe alguns.
5. Negocie e busque consenso. A força da MoSCoW está no acordo. Negocie cada fronteira com o cliente e o time até que todos concordem com a lista — inclusive com o que ficou no Won't have.
6. Registre o Won't have por escrito. Documente o que ficou de fora "desta vez". Isso evita retrabalho, encerra discussões e prepara o backlog do próximo ciclo.
7. Execute na ordem e reavalie. Entregue Musts primeiro, depois Shoulds, e use o tempo que sobrar nos Coulds. Ao fim do ciclo, repriorize tudo para a próxima entrega — o que era Won't have pode virar Must.

A regra dos 60%: por que não lotar de Must have#

O erro mais comum em quem começa na MoSCoW é transformar quase tudo em Must — afinal, tudo "parece" essencial. O DSDM ataca isso com uma regra de esforço clara e contraintuitiva: os Must have não devem passar de cerca de 60% do esforço total de uma entrega ou iteração.

A lógica é de gestão de risco. Se 100% do seu prazo está comprometido com Musts, qualquer imprevisto — uma estimativa furada, um bug difícil, uma ausência na equipe — significa não entregar algo crítico. Não há de onde tirar. Já com os Musts em 60%, sobra uma margem de manobra: quando o problema aparece, você sacrifica Coulds (e, se preciso, Shoulds) e ainda entrega tudo o que era inegociável no prazo.

Por isso a recomendação do Agile Business Consortium é manter os Musts em torno de 60% e reservar um "pulmão" saudável de Coulds, tipicamente perto de 20% do esforço. Esses Coulds são contingência pura: existem para serem cortados. Em ambientes muito conhecidos e times maduros, o percentual de Must pode ser maior; em terreno incerto, deve ser bem menor — quanto mais risco, mais folga.

Exemplo de MoSCoW na prática (caso Saborá)#

Para sair da teoria, veja a Saborá — uma fictícia startup de delivery de comida saudável de Belo Horizonte (MG). Ela tem 10 semanas e um orçamento fechado para lançar a primeira versão do app antes de uma rodada de captação. O time levantou 18 funcionalidades candidatas e todas pareciam, à primeira vista, "essenciais". Antes de sair codando, rodou a MoSCoW.

Must have (o app não existe sem isto). Cadastro e login do cliente; catálogo de pratos com fotos e preços; carrinho e fechamento de pedido; pagamento por cartão e Pix; e a tela do restaurante recebendo o pedido. Sem qualquer um desses, não há delivery — não faz sentido lançar.

Should have (importante, mas há contorno). Rastreamento do entregador em tempo real e avaliação por estrelas. Doem se faltarem, mas dá para contornar: no começo, o cliente recebe o status por notificação simples ("saiu para entrega") e a avaliação vira um formulário manual por e-mail.

Could have (bom de ter, primeiro a cair). Cupons de desconto, programa de fidelidade e modo escuro. Melhoram a experiência, mas ninguém deixa de pedir comida por falta deles. São a contingência — somam cerca de 20% do esforço.

Won't have this time (fica para depois). Assinatura mensal de refeições, integração com iFood e versão para tablet da cozinha. Boas ideias, registradas no backlog do próximo ciclo — e fora do escopo das 10 semanas, por decisão consensual.

O teste de esforço. Somados, os Musts batiam 75% do prazo — acima do teto de 60%. A direção quase aceitou, mas a regra acendeu o alerta. Eles rebaixaram "Pix" para uma fase seguinte (cartão dava conta do lançamento) e simplificaram o catálogo, trazendo os Musts para 58%. Resultado: na semana 7, um bug no gateway de pagamento consumiu dias preciosos. Como havia folga, o time cortou os Coulds (cupons e fidelidade), e entregou no prazo tudo o que era inegociável — algo impossível se a agenda estivesse 100% tomada por Musts.

MoSCoW vs Matriz RICE: qual a diferença?#

MoSCoW e RICE são dois dos métodos de priorização mais usados em produto, mas operam de formas opostas. A MoSCoW é qualitativa e baseada em consenso: agrupa itens por criticidade para uma entrega. A RICE é quantitativa e baseada em pontuação: calcula um número para ranquear itens por retorno. Uma responde "isto entra ou fica de fora?"; a outra responde "o que vale mais a pena fazer primeiro?".

RICE é a sigla de quatro fatores que entram numa fórmula: Reach (alcance, quantas pessoas afeta), Impact (impacto por pessoa), Confidence (confiança na estimativa) e Effort (esforço). O cálculo é (Reach × Impact × Confidence) ÷ Effort — quanto maior o resultado, maior a prioridade.

As duas se complementam: muitos times usam a RICE para gerar um ranking objetivo das oportunidades e, em seguida, a MoSCoW para decidir quais delas entram de fato no próximo release com prazo fechado. Vale conhecer outras duas vizinhas: o Modelo Kano, que classifica funcionalidades pelo efeito na satisfação do cliente (básicas, de desempenho e de encantamento); e a Matriz de Eisenhower, que separa tarefas por urgência × importância — mais usada para produtividade pessoal do que para escopo de produto.

Erros comuns na Priorização MoSCoW#

• Transformar quase tudo em Must: o erro mais clássico. Se os Musts passam de ~60% do esforço, o método perde a função — não sobra nada para flexibilizar quando o prazo aperta.
• Confundir importante com crítico: "o cliente vai gostar" não faz um item ser Must. A pergunta certa não é "isto é bom?", e sim "a entrega fracassa sem isto?".
• Não registrar o Won't have: deixar de documentar o que ficou de fora abre brecha para a ideia voltar como cobrança no meio do projeto, corroendo o escopo combinado.
• Priorizar sozinho: a MoSCoW vale pelo consenso. Um gestor classificando no escritório, sem cliente nem time, produz uma lista que ninguém respeita na hora do aperto.
• Esquecer o "this time": ler "Won't have" como "nunca" gera resistência política desnecessária. É "não agora" — a ideia segue viva para o próximo ciclo.
• Manter a lista congelada: prioridade é foto, não filme. O que era Could neste release pode ser Must no próximo. Repriorize a cada ciclo.

Ficha técnica da Priorização MoSCoW#