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:
Autor: Ricardo Caldas
Comments