Café com o Scrum Master Priorizando Backlog com a Técnica MoSCoW
Olá Pessoas,
Antes de mais nada eu gostaria de agradecer o wordpress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)
Prezado leitor, se você me dissesse que está pensando em dar um upgrade na carreira; investindo num treinamento para se tornar um Product Owner, e gostaria, com base na minha experiência, que eu definisse com apenas 3 verbos, o que faz (ou pelo menos deveria fazer) um PO. A resposta de bate pronto seria:
- Dividir
- Priorizar
- Descartar
Como eu sei que estes três verbos soltos não seriam suficientes, farei a seguir uma breve explanação sobre eles. Vejamos:
Dividir: Product Owners eficientes precisam saber como dividir as estórias do Product Backlog. Precisam saber fatiar as estórias, para que elas fiquem pequenas o suficiente a ponto de reduzir, consideravelmente, sua complexidade. (o time tem o dever de ajudá-los nesta tarefa)
Priorizar: Product Owners focados na entrega de valor, precisam categoricamente, priorizar as estórias do Product Backlog. Esta não é uma tarefa trivial. POs precisam estar muito próximos do time e, ao mesmo tempo, muito próximos do negócio (cliente) para que suas decisões sejam cada vez mais assertivas.
Descartar: Product Owners habilidosos devem conhecer o negócio como um especialista. Precisam ter habilidades para negociar com os clientes, features que não são necessárias no momento. POs precisam ser visionários e bons negociadores, a fim de reduzir ao máximo o que costumo chamar de escopo inchado.
Nota: Escopo inchado é aquele escopo em que o cliente solicita funcionalidades, mais ou menos, com a mesma fúria e apetite com que um esfomeado chega à um restaurante do tipo “sirva-se à vontade apenas uma vez…” – manja? – O cabra com medo de ter que pagar duas vezes, vem equilibrando num prato raso, 27 tipos de comidas diferentes… em épocas natalinas, cheguei a ver pratos com “tecos” de panetone enfiados no meio do feijão. 😕 #FomeZeroModeON
Contextualmente em ambientes de projetos, sabemos que alguns clientes (ou vários) se comportam desta mesma maneira (esfomeados); solicitam escopo com um zilhão de funcionalidades, dentre as quais, muitas são funcionalidades exóticas, que além de serem, na maioria das vezes, desnecessárias… custam muito dinheiro. Em situações como esta, somente a astúcia e a poder de negociação de um PO, dirão quais dessas funcionalidades são presente ou serão futuro… ou quem sabe nunca serão… nunca… nunca! #CapitãoNascimentoFeelings
Explicadas e consolidadas as três principais ações que um PO deve fazer, imagino que você meu caro leitor, um eterno curioso como sei que o é, esteja alimentando a dúvida 2.0. Qual seja: “Óh my Lord… um PO deve saber fazer tudo isso, e tudo isso não é fácil fazer… será que em meio a este mundaréu de técnicas, ferramentas e processos, que o mercado adora inventar, não há nada que possa auxiliar um PO a implementar estas hercúleas ações?”
FAQ da dúvida 2.0: Sim. – Utilizando a Técnica MoSCoW.
Conheci teoricamente a técnica MoSCoW, estudando PRINCE2. (PRoject IN Controled Enviroment) Esta é uma técnica muito utilizada para priorização de escopo, priorização de requisitos, classificação de mudanças e etc… Aplicando esta técnica, consegue-se, por exemplo, classificar e priorizar funcionalidades com base no seu valor de negócio.
Atualmente o Dynamic Systems Development Method (DSDM) Consortium possui os direitos de propriedade intelectual da Técnica MoSCoW, os quais foram doados pelo seu criador Dai Clegg. O PRINCE2, por sua vez, recomenda no livro Gerenciando Projetos de Sucesso com PRINCE2 o uso desta técnica em várias fases de um projeto.
A Técnica
O M do MoSCoW quer dizer Must Have (Deve Ter) – Tudo o que é imprescindível para o escopo do projeto. Aquelas funcionalidades CORE da sua aplicação, que sem elas a aplicação perderia totalmente o sentido.
O S quer dizer Should Have (Deveria Ter) – Tudo o que é importante ter no escopo do projeto, mas que não são imprescindíveis. Funcionalidades que se por ventura não forem desenvolvidas, não farão com que o produto perca o seu valor de negócio.
O C quer dizer Could Have (Poderia Ter) – Tudo o que seria bom ter, mas não são importantes. É mais ou menos como a cerejinha do bolo. Na maioria das vezes, clientes aceitam comer bolo sem cereja, até porque, bolos sem cerejas são mais baratos. 
O W quer dizer Won’t Have for Now (Não Terá por Enquanto) – Tudo o que não será desenvolvido por enquanto, pois as features classificadas com won’t have for now, não geram valor de negócio no momento.
Curiosidade: Já vi alguns backlogs e algumas pessoas estranhamente substituírem o W de Won’t Have for Now por Would Have, o que pra mim não faz o menor sentido. O Could Have existe justamente para isso. Funcionalidades classificadas com Could Have muito provavelmente serão desenvolvidas posteriormente (Would).
Vejamos um exemplo de um Product Backlog priorizado com a técnica MoSCoW (deem uma olhada na beleza e na robustez da bagaça) 😀
A Técnica e as 3 ações (Dividir, Priorizar e Descartar)
Olhando para Product Backlog acima; todas as estórias que têm valor de negócio Must Have deverão ser refinadas. Elas precisam ser entendidas pelo time, fatiadas, quebradas em estórias menores, caso elas ainda não estejam nesta condição. (DIVIDIR) – No exemplo, um sistema de contas à pagar, que não contemple relatórios de contas à pagar com filtro por data; seria um sistema que geraria valor para um cliente? Eu entendo que não…
Todas as estórias que estiverem com Must Have e Should Have são prioritárias, precisam ser desenvolvidas nesta ou na próxima sprint. (PRIORIZAR)
Todas as estórias que estiverem com Won’t Have for Now devem ser descartadas, pelo menos por enquanto. (DESCARTAR) – Voltando no exemplo do nosso Backlog, acredito que um sistema poderia, inicialmente, sobreviver sem a funcionalidade de enviar email de alerta para os usuários, toda vez que uma conta estiver a 3 dias do seu vencimento, concorda?
Algumas vantagens em utilizar a Técnica MoSCoW
- Num planejamento da release, um PO poderia tranquilamente decidir que todas as estórias que estão classificadas e priorizadas com Must Have e Should Have deverão ser implementadas até a data da release.
- Um PO poderia, analisando o avanço do projeto, incluir uma estória no Backlog, classificá-la como sendo Could Have e definir que todas as estórias classificadas com este valor de negócio, deverão ser discutidas previamente com o cliente.
- Um PO empoderado não terá maiores dificuldades em demonstrar redução nos custos do projeto, caso ele tenha classificado algumas estórias como Won’t Have for Now, e tais estórias, posteriormente, se fizeram de fato desnecessárias.
Enfim… existem N benefícios em gerenciar um Product Backlog utilizando-se da Técnica MoSCoW. Certamente esta importante ferramenta facilitará, e muito, a vida e o dia a dia dos nossos POs.
Em tempo: achei interessante uma técnica criada por americanos capitalistas, ser batizada com o nome da capital de um país (Rússia) com tradições e estigmas socialistas. 🙄
Saudações. Ψ
Café com o Scrum Master 
Quando eu vejo essa planilha até arrepia, como iniciar na área? Fiz a pós de engenharia de software, mas nada do job, estágio, voluntariado ou até fazer cafezinho acontecer rs…rs
Parabéns ficou muito bom!
CurtirCurtido por 1 pessoa
Olá Marcos,
Obrigado pelo feedback. Começar na área é fácil a parte difícil você já fez. Estudar. Sugiro que você analise o que o mercado está pedindo, busque conhecer teoricamente e seja transparente. Tenho certeza que com isso, você entrará rapidamente na área.
Conte comigo. Abraço!
CurtirCurtir
Olá Pedro.
Obrigado por compartilhar seu conhecimento conosco.
Iniciei o trabalho como PO há alguns meses em um dos principais sistemas da empresa onde trabalho e venho buscando/enfrentando o desafio de priorizar o backlog da forma mais coerente e transparente. Na minha opinião muitas das técnicas de priorização exigem um peso empírico muito grande, e não discordo, mas demonstrar valor em algo medido pelo feeling ou experiência muitas vezes pode ser díficil frente aos questionamentos dos Stakeholders. Tenho vários usuários espalhados pelo Brasil e todos eles tem necessidades diferentes. Sempre penso no valor que aquilo vai ser entregue a todos os clientes e não a um específico (embora algumas solicitações emergenciais acabam invalidando esse pensamento).
Sinto falta de algo mais sólido, de fácil visibilidade e entendimento no que foi priorizado e porquê foi priorizado, entende?!
Trabalho também dentro do setor de planejamento da empresa (outra função), onde tudo é provado com números, estudos de viabilidade e etc, então talvez seja por isso que tenho sentimento martelando em minha cabeça.
Gostaria de ouvir sua opinião a respeito. Existe alguma técnica que vá ao encontro do que eu estou buscando? Não? Estou viajando?
Abraços.
CurtirCurtido por 1 pessoa
Olá Bruno,
Grato pelo feedback!
Fico feliz que, atuando como PO, você esteja preocupado em saber como priorizar, em compreender melhor as técnicas que te auxiliem nesta tarefa muitas vezes difícil ante tantos interesses antagônicos. Acredite, existem muitos POs que nem sequer se preocupam com isso. Enfim… respondendo sua pergunta e sem querer bancar o guru, acredito que a melhor técnica de priorização é aquela que ajuda o cliente a obter valor (independentemente do que isso quer dizer pra ele), dentro de um tempo de mercado razoável, com riscos controlados e por aí vai… se você conseguir manter as priorizações considerando essas variáveis acredito que, sem se importar com esta ou aquela técnica, você estará exercendo bem o papel.
Abraços,
Pedro
CurtirCurtir
Bom dia, adorei suas dicas e inclusive gostei muito da planilha que utilizou. Você poderia fornecer seu template?
CurtirCurtir