Sprints - tempo vs qualidade | Scrum parte 6: revisão, retrospectiva e encerramento de projetos com Agile

Bom dia Frederico,

Meu nome é Filipe e sou Desenvolvedor Android.

No meu trabalho eu tenho 2 grandes problemas nas Sprints:

1 – As Sprints tem pouco tempo e devido a isso não posso entregar coisas com maior qualidade. Normalmente o produto é finalizado, porém, com mais tempo seria possível entregar algo muito superior.

2 – No Planning poker os gerentes têm o péssimo hábito de influenciar as pessoas a escolherem uma pontuação baixa, realmente eles quebram o princípio do Planning poker. Infelizmente boa parte dos gerentes vendem o Agile como uma forma de entregar mais rápido e não como uma forma de entregar mais valor.

Como posso resolver estes problemas de uma forma assertiva?

Alguns autores sugerem Sprints maiores, de até 6 semanas. Até mesmo autores renomados, não apenas livros como o SBOK.

A duração da Sprint deve ser, idealmente, determinada pelo Scrum Master - apesar de que, em questão de prova, você deve apontar o Dono do Produto como responsável pela decisão - justamente por causa da necessidade do cliente em ter em maior ou menor tempo incrementos/entregas prontas. Este é um tópico polêmico.

Se você acredita que as Sprints são curtas, talvez uma opção seja trabalhar com Kanban em um fluxo contínuo de trabalho.

Ainda, se você não consegue entregar qualidade, ou seja, atender aos requisitos do cliente, talvez eles não tenham sido bem elicitados pelo Dono do Produto ou não tenham sido bem apresentados ao time.

Sugiro que invista mais tempo no grooming do backlog em conjunto da equipe a cada Sprint.

Sobre o Planning Poker, não vamos esquecer o papel de facilitação do Scrum Master. Se o PO está tentando impor algo, o Scrum Master deve segurar a peteca dele! Deve proteger o poker deste tipo de influência.

Alias, outra prática importante é deixar o poker para o grooming, evitar usar ele nas Sprint Plannings.

Abraços,

Chegou a hora de transformar