Nos artigos anteriores escrevi sobre o que é a Equipa de Desenvolvimento, Scrum Master e Product Owner e neste artigo vou começar a escrever sobre os eventos da framework Scrum. Então vamos a isso!

Conforme está escrito no Scrum Guide, a definição de eventos é:

“Os eventos são utilizados no Scrum para criar regularidade e para minimizar a necessidade de reuniões não definidas no Scrum.”

Eventos são as “cerimónias” que existem no Scrum, incluindo a própria Sprint, que não é uma cerimónia mas é considerado um evento.

Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os artefatos do Scrum.

Estes eventos são especificamente concebidos para permitir a transparência necessária. A não realização de quaisquer eventos conforme prescrito, resulta na perda de oportunidades de inspeção e adaptação.

Idealmente, todos os eventos são realizados à mesma hora e no mesmo local para reduzir a complexidade.

Em resumo, os eventos do Scrum são:

  • Sprint;
  • Sprint Planning;
  • Daily Scrum;
  • Sprint Review;
  • Sprint Retrospective.

Neste artigo vou dar ênfase à Sprint e os próximos artigos serão sobre os outros eventos.

“O Sprint é um recipiente para todos os outros eventos.“

As Sprints são o coração do Scrum, onde as ideias são transformadas em valor e são eventos de duração fixa de um mês ou menos para criar consistência.

Todo o trabalho necessário para alcançar o Product Goal, incluindo o Sprint Planning, as Daily Scrums, a Sprint Review e a Sprint Retrospective, acontece dentro dos Sprints.

Durante a Sprint:

  • Não são feitas alterações que possam pôr em perigo o Sprint Goal; Não deveríamos ter alterações, mas acontecem;
  • Não deveríamos ter alterações, mas acontecem;
  • A qualidade não diminui; Mentira, em 90% dos casos a qualidade é duvidável;
  • Mentira, em 90% dos casos a qualidade é duvidável;
  • O Product Backlog é refinado conforme necessário; Ni! Muitas equipas não vêem valor em refinamentos;
  • Ni! Muitas equipas não vêem valor em refinamentos;
  • O âmbito pode ser clarificado e renegociado com o Product Owner à medida que mais se for aprendendo. Mais ou menos. Muitas vezes o PO é ausente e/ou está obrigado a obrigar entrar itens na Sprint por estar sob pressão dos Stakeholders.
  • Mais ou menos. Muitas vezes o PO é ausente e/ou está obrigado a obrigar entrar itens na Sprint por estar sob pressão dos Stakeholders.

Os Sprints permitem a previsibilidade, assegurando a inspeção e adaptação do progresso para um Product Goal pelo menos uma vez por mês.

Quando o horizonte de um Sprint é demasiado longo, o Sprint Goal pode tornar‐se inválido e a complexidade e o risco podem aumentar.

Sprints mais curtos podem ser utilizados para gerar mais ciclos de aprendizagem e limitar o risco de custo e esforço num período de tempo menor. Cada Sprint pode ser considerado um projeto curto.

Existem várias práticas para prever o progresso, como burn‐downs, burn‐ups ou fluxos cumulativos. Embora comprovadamente úteis, estas não substituem a importância do empirismo.

Em ambientes complexos, o que irá acontecer é desconhecido. Apenas o que já aconteceu pode ser utilizado para a tomada de decisão prospetiva.

Um Sprint pode ser cancelado se o Sprint Goal se tornar obsoleto. Apenas o Product Owner tem autoridade para cancelar o Sprint.

Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.

Espero que tenham gostado e que consigam diminuir as disfunções do dia a dia para que as equipas agile trabalhem melhor.

Nos próximos artigos vou continuar a escrever sobre os eventos do Scrum e apontar as minhas percepções / experiência sobre a framework Scrum.

Quer perceber mais sobre o Scrum e outros temas?

Inscreva-se em nossa newsletter para receber nossos conteúdos e novidades.

Até breve.

Referências:

  • Agile Manifesto
  • Scrum Guide

Autor: Ricardo Caldas