Conforme Scrum Guide 2020, não encontrei subsídios para que uma reunião de Planejamento seja cancelada. Desta forma, discordo do resultado desta questão, uma vez que é dito no Scrum Guide "O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança". Ou seja, se a User Story está confusa e extensa, ela deveria ser refinada na própria reunião de Planejamento.
Solucionado (ver solução)
Solucionado
(ver solução)
5
respostas
respostas
Cancelamento de Planning
Olá, Julio Cezar! O ponto aqui é que, conforme o enunciado, um story crucial não está adequada e "todas as demais estão em situação similar". Assim sendo, pode ficar carregado demais para a Planning ajustar a totalidade das stories, daí a necessidade da realização de um esforço prévio para que seja possível começar a carregar stories em um sprint. Se houvesse stories melhores, estas poderiam ser carregadas e trabalhadas enquanto a problemática fosse pulverizada / clarificada, mas não era o caso.
Olá Roberto,
Obrigado pelo retorno, mas continuo discordando sobre o cancelamento. Se ocorrer desta forma que você citou, creio que as primeiras stories devam ser refinadas durante a reunião, e não ter a reunião cancelada. Até porque não é obrigatório ter o backlog completo já refinado, uma vez que é um artefato vivo. As primeiras devem ser refinadas, para que a equipe possa ter com que trabalhar, e durante a sprint as outras seriam refinadas.
Por favor, poderia me auxiliar a entender desta outra forma que faz com que a reunião seja cancelada?
Isto mesmo, Julio. Pelo menos as stories prioritárias do PB devem estar "prontas" (prefiro usar este termo do que "refinadas") mas de preferência a priori (este é o papel do PO). Se nenhuma estiver, a Planning fica prejudicada. Claro que durante a Planning as stories podem ser mexidas, mas em uma situação de presença generalizadas de stories confusas, haja timebox na Planning para arrumar os artefatos. Da mesma forma, arrumar stories durante o sprint de maneira intensa prejudica a geração de software operativo, pois a equipe estará mais tempo tentando entender os requisitos do que codificando. Numa situação crítica, dar uma parada para colocar "ordem na casa" pode ser mais prudente. É situação similar ao aborto de sprint, prerrogativa do SM, caso algo dramático aconteça (sprint goal perder o sentido ou os impedimentos se avolumarem demais).
Olá!
Entendo e concordo com a parte que diz sobre dar uma parada para colocar "ordem na casa". Mas penso que o maior problema disso é realizar as justificativas para isso perante a todos os envolvidos internos, tanto os externos, stakeholders, os quais muitas vezes não entendem. E também corremos o risco de bater de frente em criar uma Sprint que não agregue valor ao produto/cliente. (Exemplo de correções de débitos técnicos)
Sendo assim, entendo a teoria que foi explicada, porém ainda vejo algumas dificuldades na implementação das mesmas. Acredito que quanto mais colocarmos em prática, mais poderemos ajudar nesse quesito.
Agradeço os esclarecimentos e a troca de conhecimentos, as quais sempre são produtivas.
Julio Quirino
solução!
Realmente, Julio, metodologia de desenvolvimento não é uma ciência exata e cada contexto importa.