top of page
Foto do escritorRicardo Caldas

Eventos Scrum & Sprint

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;

  • A qualidade não diminui;

    • 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;

  • 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.


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:


9 visualizações0 comentário

Posts recentes

Ver tudo

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page