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

Realmente, Julio, metodologia de desenvolvimento não é uma ciência exata e cada contexto importa.