BT

Como convencer o Product Owner a priorizar o Backlog?

por Dan Puckett , traduzido por Pedro Mariano em 13 Dez 2010 |

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.

 

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.