Semanas atrás, algumas pessoas do meu time que não tiveram muito contato com metodologias ágeis pediram que eu contasse um pouco sobre a aplicação do Scrum nos meus projetos anteriores, evidenciando sobre como os eventos scrum eram tocados.

Percebi que contar um pouco sobre minhas experiências positivas em times que aplicavam Scrum é uma tarefa recorrente, então decidi escrever sobre isso! 😃

Atenção!

⚠️ >>
Este texto não irá debater ou apresentar definições. Caso tenha interesse nas definições sobre os eventos citados, recomendo consultar o Scrum Guide.

E se você está começando a estudar sobre agilidade, vale consultar o Manifesto ágil.

Agilidade não se resume a Scrum.

Algumas das práticas apresentadas no texto funcionavam bem em determinados contextos. Os desafios e as escolhas que são feitas dependem muito das pessoas e do contexto.
Não existe uma solução geral (bala de prata) que funcione para todos os casos.
<< ⚠️

Eventos Scrum

Os seguintes eventos são citados no Scrum Guide e apresentados na sequência do texto:

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Além dos eventos citados no Scrum Guide, será apresentada também a dinâmica de um Refinamento.

Sprint 🏃

⌛ 2 semanas (geralmente, no meu caso)
É quando o que foi planejado é executado. Para melhorar a agilidade no desenvolvimento de software costumávamos nos valer de testes automatizados (como documentação viva do código, segurança para o time fazer as alterações necessárias no código), CI/CD (facilitando o processo de deployment de software) e técnicas como pair programming.
Quando itens inesperados surgiam, o "objetivo do sprint" era utilizado como critério para decisão da priorização entre itens planejados e não planejados. Quando os itens não planejados eram adicionados ao "Sprint Backlog", algum item planejado era despriorizado, para não onerar o time.

Sprint Planning 🎯

📅 Após a retrospectiva
⌛ 2h-4h
Nas sessões de planejamento do sprint os itens refinados (aptos a serem desenvolvidos no próximo sprint) eram revisados. Os itens eram puxados pelo time de desenvolvimento, conforme a priorização estabelecida no product backlog, de acordo com o quanto o time acreditava que conseguiria produzir e se comprometer.
Para ajudar a entender, e obter certa previsibilidade, sobre o quanto um time costumava produzir durante um sprint, algumas equipes utilizavam sistemas de estimativas e técnicas: story points, tamanhos de camiseta (P, M, G), planning poker.
Ao término da sessão de planejamento do sprint, o time saía com a definição do "objetivo do sprint", que ajudaria o time a se organizar e inspecionar constantemente se as ações tomadas durante o sprint estão contribuindo para o atingimento do objetivo. A definição do objetivo sprint era muito útil para tomadas de decisão sobre a priorização dos itens no decorrer do sprint, conforme itens inesperados surgiam.

Daily Scrum 🔁

📅 Diariamente
⌛ Até 15 minutos
As dailies tinham foco em traçar o plano para as próximas 24h e avaliar se estávamos continuamente avançando em busca do objetivo do sprint. Impedimentos eram declarados e as pessoas se organizavam para superar os bloqueios ou notificar quem fosse necessário.
Quando trabalhando com times distribuídos, geralmente os times faziam a daily olhando para as tasks no board, desta forma trabalhos invisíveis eram identificados (e cadastrados no Jira), o quadro era atualizado diariamente, verificava-se quais os cards estavam parados há muito tempo, era possível notar em uma cadência diária se o time estava se aproximando do objetivo traçado no Sprint Planning, em vez de perceber isso apenas no Review.

Sprint Review 🎁

📅 No término do sprint
⌛ 1h-2h
Neste evento, apresentávamos as entregas do time e o valor que foi gerado, com foco em dar visibilidade do que foi feito e compartilhar o conhecimento entre todos. Além de fazer uma "demo", era importante contar com feedbacks e insights do time que ajudavam a definir melhorias, mudanças e os próximos passos que poderiam ser priorizados (resultando na atualização do Product Backlog).

Sprint Retrospective 📣

📅 Após o sprint review
⌛ 1h-1h30
Constituía na etapa de inspeção contínua do ciclo, uma oportunidade para notar o que estava dando certo e tínhamos interesse em continuar fazendo, e também identificar o que não estava tão legal e queríamos melhorar.
O ponto chave aqui era extrapolar os próprios pontos, e elaborar planos de ação do time que seriam acompanhados e monitorados. Os formatos variavam de conversas casuais à clássica utilização do board (utilizávamos esse board online). Tinha um pessoal que gostava de acessar esse site para aprender novos formatos de retrospectiva.

Refinamento 🔬

📅 Antes do planning
⌛ 1h
Esse evento não está listado no ScrumGuide, mas fazíamos em alguns times (principalmente para os times que precisavam de maior previsibilidade). O objetivo era refinar os itens de backlog.
O refinamento poderia indicar que o item não estava pronto para ser implementado (possivelmente devido a algum pré-requisito não mapeado que faria com que o item ficasse para o próximo sprint), ou que o item era muito grande e poderia ser dividido em mais partes. O refinamento era utilizado também como alinhamento técnico entre os engenheiros que poderiam discutir como o item seria implementado.
Para times que estimavam tarefas, era uma reunião bastante útil, pois as dúvidas eram antecipadas, evitando que as plannings ficassem muito extensas.

E você, como aplica os eventos Scrum?

Neste texto pude apresentar algumas experiências que tive aplicando os eventos Scrum no meu dia-a-dia profissional.

Você aplica de uma forma parecida? De uma forma completamente diferente? Te pareceu interessante ou errado?
Conta pra gente nos comentários! 😉

Referências

• Manifesto ágil. Disponível em 16/02/2021: https://agilemanifesto.org/iso/ptbr/manifesto.html
• Scrum guide. Disponível em 16/02/2021: https://www.scrumguides.org/scrum-guide.html
• Frederick P. Brooks. No Silver Bullet. Disponível em 16/02/2021: http://worrydream.com/refs/Brooks-NoSilverBullet.pdf