O que deve ser evitado durante o Sprint Planning
A cerimônia Sprint Planning é o momento onde é definido quais atividades serão executadas durante a próxima Sprint. O objetivo desta é atingir com o time o comprometimento do que será feito durante este ciclo.
O que o PO deve evitar a todos os custos para esta cerimônia?
1- Iniciar a Sprint Planning sem um objetivo claro
O PO tem como obrigação definir a direção que o time seguirá, isso significa que um objetivo claro deve ser definido antes de iniciar a reunião. Por muitas vezes, o objetivo não é definido e uma série de user stories sem conexão uma com a outra são priorizadas, quando isso acontece o time tende a se dividir para poder finalizar a Sprint. Este é um efeito muito ruim, pois perde-se o benefício do trabalho em equipe, uma vez que cada membro vai para um objetivo diferente.
Quando o objetivo é claramente definido, fica mais fácil definir as user stories que são aderente ao objetivo, desta forma garantindo que o time trabalhará em conjunto para atingir o comprometimento.
2- Forçar o time a aceitar mais tarefas do que a capacidade
Durante o início da Sprint Planning, o PO deve apresentar o objetivo da Sprint e após isso o time de desenvolvimento apresenta a capacidade que terá para este ciclo, tal definição é de total responsabilidade do time. O PO deve respeitar e confiar na capacidade definida pelo time, ao invés de forçar o time a se comprometer com mais user stories. Obviamente o PO tem como missão maximizar o valor entregue ao negócio, porém deve ser lembrado que número de user stories entregue não reflete diretamente com valor entregue.
O time de desenvolvimento é quem sabe a capacidade do que poderá ser entregue.
O que eu particularmente gosto de fazer é juntamente do time, definir o escopo da Sprint, então faço a pergunta se as user stories estão adequadas ou precisamos fazer modificações, como remover ou incluir. Quanto maior a colaboração com time, maior será a facilidade em encontrar um balanço ideal para o comprometimento.
3- Não se escreve User Stories durante a Sprint Planning
É um cenário que pode ocorrer quando alguma dependência é descoberta durante a planning, tal que o time de desenvolvimento não poderia trabalhar em User Story A pois precisa que B seja feito inicialmente, porém B ainda não existe. Para evitar o atraso do desenvolvimento o PO pode querer escrever a User Story durante a Planning, porém tal atividade não é aconselhável, pois a User Story tende a ser escrita superficialmente, bem como o refinamento e a comunicação com o time.
Quando este cenário ocorrer, o PO bem como o time devem aprender a como evitar tal situação, por exemplo, discutindo mais durante o refinamento (Grooming) para descobrir eventuais dependências.
Na Sprint Planning apenas são consideradas User Stories que estão prontas para serem trabalhadas, ou seja, escritas, refinadas e estimadas. Então evite ao máximo o cenário de criar User Stories durante a planning.
Quer saber mais sobre este tema? Se inscreva em meu curso Como ser um Product Owner.
