Planejamento de Sprint - Quando remover uma história?

Se a falta de conhecimento for de negócio e o PO não consegue sanar é comum não colocar no Sprint, porém como o PB já estava priorizado o ideal era que ela entrasse.

A idéia era tentar fazer com que isso não acontecesse mais, por exemplo o PO poderia pedir um dia antes para alguém de Dev dar uma ajuda para ver se as histórias estão claras o suficiente. O PO tem que ter essa visão de negócio para conseguir ajudar na maior parte das dúvidas, mas em começo de projeto ou em tarefas mais dificeis é comum acontecer bastante dúvidas.

Se mesmo assim continuar com problemas, a idéia é tentar trazer o cliente ou usuário para reunião quando o PO achar que as tarefas não estão tão claras.

Se o cliente não puder participar da reunião a idéia é que se o time tem uma idéia da tarefa discute por cima e depois o PO confirmar se realmente era aquilo. Se não der para entender nada a idéia é que a tarefa é importante e o PO deve após a reunião tirar as dúvidas e discutir depois com o time, mas em geral essa prática atrapalha bastante o planejamento e não é muito recomendável.

É trabalho do PO trazer as histórias bem descritas e se isso está acontencendo com frequência cabe uma reeducação do PO.

Espero que tenha ajudado.

Obrigado Marcio pela resposta. Analisando agora pelo o que você escreveu e pensando um pouco mais no processo atual, uma coisa que fica evidente é que o PO muitas vezes está abarrotado, ou seja, ele está em mais de um projeto ao mesmo tempo(normalmente 2 e as vezes até 3). Nesse caso quando chega o dia de realizar o planejamento da sprint, o PO apesar de ter priorizado as tarefas, a parte do detalhamento não fica boa o suficiente para a equipe conseguir estimá-las. Nesse caso, ele acaba usando esse momento para detalhá-las e ai algumas coisas acabam não sendo realmente da melhor forma. Creio que sua sugestão de ter alguém do desenvolvimento para ajudá-lo um dia antes minimizaria esses problemas assim como a reeducação do PO. Dando uma revisada nas aulas do curso de agile, teve o conceito de reuniões de Backlog Grooming, que se conseguirmos colocá-la, também ajudará em um melhor detalhamento.

Só uma observação, no nosso caso como estamos aos poucos implantando o Scrum, quem faz o papel do PO é o próprio analista de sistemas.

Abraço e obrigado novamente!

É recomendado inclusive no SAFe (Scaled Agile Framework) que o PO tenha no máximo dois times ao seu comando. Deve-se pensar melhor antes de assumir duas equipes justamente para evitar esses tipos de problema. Alguns dos itens do backlog podem ser quebrados e detalhados junto com a equipe mesmo. O importante é não deixar a equipe parada enquanto dúvidas são tiradas com o cliente. Quanto mais o projeto caminha, mais informações o PO terá. Lembre-se que de inicio o cliente não sabe realmente o que quer, por isso o time deve estar aberto a mudanças e abraça-las quando surgirem.