O "scrumnoob" tem um problema com Scrum em seu projeto atual. O Product Owner (P.O.) não está priorizando o backlog de forma correta. O "scrumnoob" escreveu:
O PO é excelente quando o assunto é o conhecimento do produto, gerenciamento dos negócios etc, e ele está comprometido com a idéia de sprints/demo's e retrospectivas. Ele acha o product backlog e a priorização do mesmo um tanto quanto pura e não compra a idéia. A abordagem dele é que nós precisamos entregar tudo o que foi passado em determinada data, independente de priorização.
O que o "scrumboob" deveria fazer nessa situação?
"woynam" sugere lidar com essa disfunção pedindo ao product owner para ordenar o backlog levando em conta outros fatores além do valor ao cliente:
Se *tudo* no backlog precisa ser entregue (duvidoso), então existem outras maneiras de se priorizar o backlog.
Uma pode ser a priorização baseada no risco técnico, a qual certamente afeta o risco do negócio. Existem funcionalidades que são difíceis de implementar, ou que possuem um alto nível de incerteza? Implementar estas primeiramente pode reduzir o risco de surpresas no caminho, dado que se deixadas para depois já pode ser tarde de mais.
O backlog poderia ser organizado por tema. Histórias que possuem a mesma área funcional devem ser implentadas juntas, com isso se você precisa lançar o projeto antes, você já possui uma lista coesa de funcionalidades.
Existe algum evento onde você precisa de uma versão demo? Se sim, então o que faria sentido ter nessa demo?
Dave Rooney sugere utilizar a pressão baseada em qualidade-versus-tempo que naturalmente surge em projetos para ajudar a persuadir o product owner:
[...] antes de adotar Scrum, a organização estava utilizando processos tradicionais com uma bateria de testes justamente na última fase? Se sim, esta fase sempre era "espremida" com a intenção de poder lançar mais funcionalidades? Se sim, qual era a qualidade, ou talvez a melhor pergunta seja quantos testes e quanto re-trabalho tinha que ser feito para que o release fosse entregue? Com essa informações, você pode perguntar ao PO quais são as funcionalidades ele gostaria de ver prontas prioritariamente antes do período de crise onde a qualidade acaba dando uma "passeada".
Peter Stevens recomenda enquadrar o problema da priorização em um perspectiva maior de negócio:
Você sabe, isso é igual ao clássico padrão: Os negócios não podem/não irão/não colocam prioridades, então alguém do grupo de desenvolvimento vai e faz o trabalho sujo. Isso não é realmente bom para otimizar o valor, mas significa que a priorização acontece (e então o negócio é poupado do trabalho pesado e pode culpar o desenvolvimento por fazer errado). É assim que sua organização deseja ser? Você deseja continuar com esse padrão mesmo utilizando o Scrum?
Dave Rooney sugere que o time de desenvolvimento coloque suas próprias prioridades, mas que faça priorize da forma errada a fim de incentivar o product owner a entrar em ação:
Você possui uma idéia dos items que "deveriam" ter uma prioridade maior? Se sim, além de dizer ao Product Owner: "Ok, então nós iremos fazer essas tarefas primeiro". Escolha primeiro os items de menor prioridade. Então diga, "Iremos deixar esses items lá para o final", selecionando os items de maior prioridade.
Outra possível estratégia é colocar os items do backlog de forma aleatória.
O Product Owner repentinamente terá uma melhor idéia do que é uma prioridade alta. ;)
Mas David Koontz não concorda muito com a idéia acima:
Eu não sugeriria trabalhar com os items de baixo valor para ganhar atenção - isso seria maldoso e não é produtivo para a relação ou para o sucesso do time. O time é responsável, se o PO não está fazendo sua parte - todos podem faze-lá. O time pode entender o valor da história tão bem quanto o PO - eles devem fazer o melhor que podem a fim de definir uma prioridade sustentável.
Não importanto qual solução será escolhida, Charles Bradley recomenda que o ScrumMaster deve tratar esse problema como um impedimento comum do Scrum:
De quem foi a decisão de escolher o Scrum? Qual processo você utilizava antes?Quem ficará nervoso se você não entregar nenhuma história no próximo sprint?
A quem o PO se reporta?
A quem você se reporta? Você é o ScrumMaster?
Meus questionamento são no sentido de tratar essa questão como um impedimento, sendo assim o ScrumMaster deve trabalhar para resolver o mesmo, provavelmente a maior parte do tempo fora do time.