Método MoSCoW: Priorize Requisitos do Jeito Certo

O método MoSCoW é um dos frameworks de priorização mais práticos disponíveis para equipes de projeto, e leva cerca de trinta minutos para aprender e uma vida inteira de disciplina para aplicar bem. A maioria das equipes não falha por escolher a ferramenta errada. Falha porque diz sim para tudo e acaba não entregando nada útil dentro do prazo.

O que é o método MoSCoW?

O método MoSCoW é uma técnica estruturada de priorização usada em gerenciamento de projetos, desenvolvimento de produto e análise de negócios para classificar requisitos, funcionalidades ou tarefas em quatro categorias com base em sua importância e urgência. Cada letra do acrônimo corresponde a uma categoria:

• Must have: Requisitos não negociáveis. O projeto falha sem eles.
• Should have: Importantes, mas não críticos. Agregam valor significativo e devem ser incluídos se possível.
• Could have: Funcionalidades desejáveis, mas opcionais. Inclua-as apenas se o tempo e o orçamento permitirem sem comprometer os Must-haves.
• Won't have (this time): Explicitamente fora do escopo desta entrega. A expressão "this time" importa, pois esses itens podem aparecer em uma iteração futura.

O framework foi desenvolvido por Dai Clegg na Oracle UK em 1994 e posteriormente formalizado no Dynamic Systems Development Method (DSDM). As letras minúsculas em MoSCoW (os "o"s e o "W") são preenchimento para tornar o acrônimo pronunciável. As quatro letras com significado são M, S, C e W.

Dados relevantes

• O Standish Group CHAOS Report constatou que 45% das funcionalidades em produtos de software nunca são usadas, e outras 19% são usadas raramente, o que significa que quase dois terços do que as equipes constroem geram valor mínimo (Standish Group CHAOS Report, 2020).
• Projetos que usam priorização estruturada de requisitos têm duas vezes mais probabilidade de serem entregues no prazo e dentro do orçamento em comparação com aqueles sem priorização formal (PMI Pulse of the Profession, 2021).
• Equipes que definem claramente os itens fora do escopo no início do projeto reduzem as mudanças de escopo no meio do projeto em até 30% (pesquisa de profissionais do DSDM Consortium, 2019).

As quatro categorias MoSCoW

A divisão 60/20/15/5 é um guia aproximado, não uma regra. A restrição crítica é que os Must-haves nunca devem exceder a capacidade de entrega confirmada da equipe. Se excederem, a categorização está errada, não a capacidade.

MoSCoW vs outros métodos de priorização

O MoSCoW é geralmente o framework mais rápido de aplicar em um workshop com partes interessadas porque usa categorias em linguagem simples em vez de pontuações ou curvas. Isso o torna especialmente útil quando você precisa de aprovação de partes interessadas não técnicas antes do planejamento do Sprint ou do kickoff de entrega.

Benefícios da priorização MoSCoW

Cria uma linguagem compartilhada. Quando um gerente de produto diz "isso é um Should", todos na equipe sabem o que significa. Ninguém perde tempo perguntando se uma funcionalidade é "importante" (tudo é importante para quem a solicitou).

Força escolhas explícitas. A categoria Won't-have é a parte mais poderosa do framework. Escrever o que você não está construindo é mais difícil do que parece, e isso evita que o escopo se expanda silenciosamente após o kickoff.

Alinha as partes interessadas antes do início do trabalho. Executar um workshop MoSCoW com a matriz RACI completa de partes interessadas revela discordâncias sobre prioridades cedo, quando são baratas de resolver. Conflitos de prioridade nas fases finais são caros.

Encaixa-se naturalmente na entrega ágil. O framework combina bem com a metodologia ágil porque delimita cada iteração em vez do projeto inteiro. As equipes reexecutam o MoSCoW no início de cada ciclo de release, em vez de travar os requisitos de uma vez só.

Protege os Must-haves. Ao dar aos itens de maior prioridade seu próprio balde protegido, o framework torna mais fácil do ponto de vista político dizer não a adições. "Isso desbancaria algo dos Must-haves" é um argumento mais difícil de descartar do que "simplesmente não temos tempo."

Erros comuns

1. Muitos Must-haves. Este é o modo de falha mais comum. Quando tudo é crítico, nada é. Uma lista saudável de Must-haves deve caber dentro da capacidade de entrega confirmada com margem para o inesperado. Se seus Must-haves consumirem 90% da capacidade, você não tem buffer para problemas técnicos e tornou os Should-haves irrelevantes.

2. Sem lista de Won't-have. Equipes que pulam esse balde deixam o escopo ambíguo. As partes interessadas preenchem essa ambiguidade com suposições. Defina a lista de Won't-have por escrito e compartilhe com todos que aprovaram os Must-haves.

3. Tratar as categorias como permanentes. O MoSCoW é uma avaliação em um momento específico para uma janela de entrega específica. Um Could-have no release um pode se tornar um Must-have no release dois. Revise a categorização no início de cada iteração.

4. Usar MoSCoW sem uma restrição de tempo. O framework só funciona quando você está priorizando em relação a um prazo ou orçamento fixo. Sem uma restrição, tudo permanece como Must-have porque não há força motriz para escolher.

5. Executar o workshop sem as partes interessadas certas. A categorização feita por um único analista ou gerente de projeto sem envolvimento das partes interessadas produz uma lista que ninguém possui. A sessão precisa das pessoas que vão conviver com as escolhas.

6. Confundir Should-have com Could-have. Um Should-have é algo que o negócio sente falta ativamente se estiver ausente. Um Could-have é uma melhoria agradável. A distinção importa quando você está decidindo o que cortar sob pressão.

Como usar o método MoSCoW

Passo 1: Colete os requisitos

Reúna todos os requisitos, funcionalidades, histórias de usuário ou tarefas que são candidatos para a entrega. Nesta etapa, não filtre nada. Você quer uma lista completa antes de começar a classificá-la. Use a declaração de escopo do projeto como documento de limite para confirmar o que está dentro e fora do projeto geral.

Uma matriz de análise de partes interessadas ajuda a identificar cujas contribuições você precisa durante o workshop de priorização. Diferentes partes interessadas são responsáveis por diferentes requisitos, e sua autoridade relativa molda como os conflitos são resolvidos.

Passo 2: Alinhe as definições das categorias

Antes de a equipe começar a categorizar, reserve cinco minutos para confirmar o que cada balde significa neste contexto específico. Para alguns projetos, "Must have" significa exigido legalmente. Para outros, significa tecnicamente necessário para o MVP funcionar. Alinhar a definição antes de categorizar evita que a sessão trave a cada segundo item.

Passo 3: Categorize de forma colaborativa

Com todos os requisitos visíveis (um quadro branco, post-its ou uma planilha compartilhada), a equipe atribui cada item a um balde. Percorra a lista sistematicamente. Para cada requisito, pergunte:

• O produto seria inutilizável ou não conforme sem isso? Se sim, é Must.
• Entregaríamos com arrependimento significativo se estivesse ausente? Se sim, é Should.
• Adicionaríamos se tivéssemos tempo de sobra? Could.
• Está fora do escopo desta entrega? Won't (this time).

Discordâncias nesta etapa são saudáveis. Revelam expectativas desalinhadas com antecedência. Resolva-as agora, não durante o standup diário do Scrum três semanas depois.

Passo 4: Verifique o orçamento de Must-have

Assim que a categorização inicial estiver concluída, some o esforço estimado para todos os itens Must-have. Compare esse total com sua capacidade de entrega confirmada (horas disponíveis ou Story Points menos um buffer de contingência de 20%). Se os Must-haves excederem a capacidade, algo precisa ser movido. Rebaixe os Must-haves mais fracos para Should-haves até que os números se encaixem.

Esta etapa é onde o MoSCoW compensa o investimento. Sem ela, as equipes descobrem o excesso de comprometimento no ponto de dois terços do projeto, quando já é tarde demais para ajustar com graça.

Passo 5: Revise e revise em cada iteração

No início de cada Sprint ou ciclo de release, reveja a lista. Os itens concluídos saem. Novas descobertas, necessidades de negócio em mudança ou restrições técnicas podem mudar itens entre categorias. A lista Won't-have da iteração anterior é a melhor fonte de candidatos para promoção a Could-have ou Should-have na próxima.

Esse ciclo de revisão é o que mantém o MoSCoW alinhado com a realidade, em vez do plano original. Um termo de abertura do projeto define o limite estratégico; o MoSCoW mantém a execução tática dentro desse limite.

Exemplo MoSCoW

A tabela abaixo mostra uma lista de funcionalidades para o MVP de um portal de projetos voltado para clientes, classificada por categoria MoSCoW.

Os Must-haves definem um produto funcional. Os Won't-haves definem o limite de negociação com partes interessadas que querem tudo no primeiro dia.

Melhores práticas

Execute o MoSCoW como um workshop, não como um exercício individual. A discussão durante a categorização é onde o alinhamento acontece. Uma planilha preenchida por uma única pessoa e enviada por e-mail não produz o mesmo comprometimento compartilhado.

Escreva Must-haves como critérios de aceitação, não como nomes de funcionalidades. "Login seguro" é ambíguo. "Um usuário pode fazer login com e-mail e senha, a sessão expira após 30 minutos de inatividade e tentativas de login com falha são limitadas por taxa" é testável. Critérios claros facilitam a confirmação de quando um Must-have está de fato concluído.

Mantenha a lista Won't-have visível ao longo de todo o projeto. Imprima-a, fixe-a, coloque-a no cabeçalho do board Scrum vs Kanban ou publique-a no canal da equipe. Itens fora do escopo têm o hábito de reentrar silenciosamente no escopo quando ninguém está monitorando.

Use o MoSCoW junto com seu processo de estimativa, não em vez dele. Priorização sem estimativas de capacidade é otimismo sem fundamento. Execute a verificação do Passo 4 sempre que atualizar a lista.

Seja honesto sobre o que "Won't have this time" significa. Não é uma rejeição educada. É um adiamento programado. Se você sabe que um item nunca será construído, diga isso claramente em vez de deixá-lo indefinidamente em Won't-have. Equipes e partes interessadas merecem clareza.

Perguntas frequentes

Para que serve o "o" em MoSCoW?

Para nada. Os "o"s minúsculos são letras de preenchimento adicionadas para tornar o acrônimo pronunciável. As quatro letras com significado são M (Must have), S (Should have), C (Could have) e W (Won't have). Dai Clegg cunhou o termo na Oracle em 1994, e a capitalização incomum é intencional para sinalizar que apenas quatro das seis letras têm significado.

Que percentual de requisitos deve ser Must-have?

Não há uma regra universal, mas a maioria dos profissionais recomenda que os requisitos Must-have consumam no máximo 60 a 70% da capacidade de entrega disponível. Isso deixa espaço para Should-haves e um buffer de contingência. Se seus Must-haves consistentemente atingem 80 a 100% da capacidade, você não está priorizando, está apenas listando tudo que planeja construir.

Um requisito pode mudar entre categorias?

Sim, e deve. O MoSCoW é uma ferramenta dinâmica. Um Should-have em um Sprint pode se tornar um Must-have no próximo se uma mudança regulatória ou um compromisso com um cliente mudar sua importância. Revise e atualize as categorias no início de cada iteração em vez de tratar a categorização inicial como definitiva.

Como o MoSCoW se encaixa na entrega ágil?

O MoSCoW se encaixa naturalmente no Agile porque ambas as abordagens adotam iteração e escolhas. Em um contexto ágil, o MoSCoW delimita cada Sprint ou release em vez do Roadmap completo do produto. O Product Owner geralmente conduz o workshop de categorização antes do planejamento do Sprint. O Backlog do Sprint é então elaborado a partir dos Must-haves primeiro, Should-haves se a capacidade permitir e Could-haves apenas se houver Slack confirmado.

Quem deve facilitar a sessão MoSCoW?

O gerente de projeto ou analista de negócios geralmente facilita, mas a sessão deve incluir todas as partes interessadas com autoridade de decisão sobre os requisitos. Isso geralmente significa o Product Owner ou patrocinador, os principais líderes técnicos e qualquer função de negócio com participação significativa na entrega. O papel do facilitador é manter a conversa avançando e garantir que as discordâncias sejam resolvidas (não adiadas) antes do término da sessão.

---

Priorização não é uma habilidade técnica. É uma disciplina de tomada de decisão, e o MoSCoW dá a essa disciplina uma estrutura que a maioria das equipes pode realmente usar sem uma certificação ou uma planilha de pontuação. Comece com uma lista completa de requisitos, execute o workshop com as pessoas certas, proteja os Must-haves do excesso de comprometimento e escreva o que você não está construindo. O restante se seguirá.

Leitura relacionada

• O que é Metodologia Agile?
• Planejamento de Sprint: Como Conduzir uma Reunião de Planejamento de Sprint Eficaz
• O que é Scrum?
• Scrum vs Kanban
• Declaração de Escopo do Projeto
• Matriz RACI
• Termo de Abertura do Projeto
• Matriz de Análise de Partes Interessadas