Must

O que precisamos entregar de qualquer jeito?

Implementar os recursos de segurança essenciais para proteger os dados dos usuários
Cumprir os requisitos regulatórios antes do lançamento
Corrigir os bugs críticos que afetam os principais fluxos dos usuários
Should

O que é importante, mas não crítico?

Implementar a busca avançada
Adicionar melhorias de desempenho
Criar a documentação completa para o usuário
Could

O que seria bom ter se sobrar tempo?

Adicionar a opção de tema escuro
Implementar suporte a mais idiomas
Criar uma versão em app mobile
Won't

O que estamos combinando não fazer desta vez?

Construir integração com blockchain nesta fase
Dar suporte a versões antigas de navegadores
Desenvolver soluções de hardware próprias

O que é o método de priorização Must Should Could Won't?

O Must Should Could Won't, mais conhecido como MoSCoW, divide o trabalho em quatro grupos: o que vocês precisam fazer, o que deveriam fazer, o que poderiam fazer se sobrar tempo e o que não vão fazer desta vez. Usado como retrospectiva, ele faz o time combinar em voz alta, com todo mundo presente, as prioridades da próxima sprint ou release. Dai Clegg criou o método na Oracle nos anos 1990, e ele virou parte padrão da gestão ágil de projetos e da análise de negócios, principalmente no DSDM. As categorias são Must have (crítico), Should have (importante), Could have (desejável) e Won't have (não desta vez). Ele combina com o jeito ágil de trabalhar porque coloca em primeiro lugar o trabalho de maior valor. Também dá ao product owner uma forma estruturada de enxergar o backlog pelo lado do cliente: se o cliente sentiria falta de algo no lançamento, provavelmente é um Must. A coluna Won't faz mais do que parece. Registrar o que vocês combinaram não fazer impede que isso volte de mansinho para a sprint e deixa claro para os stakeholders o que não será entregue.

Formato Must Should Could Won't

Must

O que precisamos entregar de qualquer jeito?

São requisitos inegociáveis, críticos para o sucesso. Ao discutir os itens de 'Must', incentive os participantes a pensar em bloqueios reais ou elementos essenciais sem os quais o projeto fracassaria. Desafie o time a ser rigoroso sobre o que realmente conta como 'Must' para evitar a inflação de prioridades.

Should

O que é importante, mas não crítico?

São funcionalidades ou requisitos importantes que agregam bastante valor, mas não são críticos para o lançamento. Oriente o time a pensar em itens que fariam falta se ficassem de fora, mas que não impediriam o projeto de funcionar. Foque em itens de alto valor e menor urgência.

Could

O que seria bom ter se sobrar tempo?

São funcionalidades desejáveis, que seria bom ter se os recursos permitirem. Ajude o time a identificar melhorias que deixariam a solução melhor, mas que não são essenciais. Esses itens costumam ser bons candidatos para iterações ou releases futuras.

Won't

O que estamos combinando não fazer desta vez?

São itens que o time decide explicitamente não fazer nesta iteração ou projeto. Incentive uma discussão honesta sobre funcionalidades que até poderiam valer a pena, mas não se encaixam nos objetivos ou restrições atuais. Dar nome a esses itens mantém o time focado e deixa as expectativas claras.

Quando utilizar esta análise retrospectiva

  • Ao planejar um novo projeto ou iniciativa e vocês precisarem de prioridades claras
  • No refinamento do backlog, para organizar e priorizar pedidos de funcionalidades
  • Quando os recursos estão apertados e é preciso tomar decisões difíceis sobre escopo
  • Em reuniões com stakeholders, para alinhar expectativas sobre o que será entregue e quando

Perguntas sugeridas para quebra-gelo

  • Qual foi a decisão de prioridade mais difícil que você já teve que tomar em um projeto?
  • Se você pudesse entregar só três funcionalidades no seu projeto atual, quais seriam e por quê?

Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →

Ideias e dicas para sua reunião de retrospectiva

  • Mantenha os itens de Must em no máximo cerca de 60% do esforço total, conforme a orientação do DSDM, para que o plano tenha folga para imprevistos
  • Revise as categorias à medida que as necessidades e restrições do negócio mudarem
  • Defina um tempo limite para discutir cada item, para que um único debate não tome a reunião inteira
  • Registre por que cada item ficou onde ficou, para que o próximo debate não comece do zero
  • Envolva os stakeholders responsáveis pelos requisitos, para que as prioridades se mantenham
  • Verifique as dependências antes de classificar um item: um Could do qual um Must depende é, na verdade, um Must

Perguntas frequentes

O que é o método MoSCoW?
O MoSCoW é uma técnica de priorização que divide o trabalho em quatro categorias: Must have, Should have, Could have e Won't have desta vez. Dai Clegg o criou na Oracle nos anos 1990, e ele é muito usado em agilidade e análise de negócios.
O que significam Must, Should, Could e Won't?
Must é essencial e inegociável. Should é importante, mas não crítico, Could é desejável se sobrar tempo, e Won't é o que foi combinado como fora do escopo por enquanto.
Como conduzir uma retrospectiva MoSCoW?
Liste os itens de trabalho candidatos, discuta cada um em time e coloque-o na coluna Must, Should, Could ou Won't. Questione cada Must e cheguem a um acordo sobre cada item antes de passar para o próximo.
Por que se chama MoSCoW?
As letras maiúsculas representam Must, Should, Could e Won't. Os dois "o" estão lá só para tornar a sigla pronunciável.
Quantos itens devem ser Must?
O DSDM, framework ágil que popularizou o MoSCoW, recomenda manter os Musts em no máximo cerca de 60% do esforço. Se quase tudo é Must, o time não priorizou de verdade.
Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva