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