Eventos Scrum: um relato de experiência
Tags: scrum, agile, ptbr, agilidade
Published: 2021-04-13 12:06:58

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! :smiley:

### Atenção!
:warning: >>
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](https://www.scrumguides.org/scrum-guide.html).

E se você está começando a estudar sobre agilidade, vale  consultar o [Manifesto ágil] (https://agilemanifesto.org/iso/ptbr/manifesto.html).

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](http://worrydream.com/refs/Brooks-NoSilverBullet.pdf)) que funcione para todos os casos.
<< :warning:


## Eventos Scrum
Os seguintes eventos são citados no Scrum Guide e apresentados na sequência do texto:
- [Sprint](#sprint)
- [Sprint Planning](#planning)
- [Daily Scrum](#daily)
- [Sprint Review](#review)
- [Sprint Retrospective](#retrospectiva)

Além dos eventos citados no Scrum Guide, será apresentada também a dinâmica de um [Refinamento](#refinamento).

### <a name="sprint"></a>Sprint :runner:
:hourglass: 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. 

### <a name="planning"></a>Sprint Planning :dart:
:date: Após a retrospectiva
:hourglass: 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.

### <a name="daily"></a>Daily Scrum :repeat:
:date: Diariamente
:hourglass: 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.

### <a name="review"></a>Sprint Review :gift:
:date: No término do sprint
:hourglass: 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).

### <a name="retrospectiva"></a>Sprint Retrospective :mega:
:date: Após o sprint review
:hourglass: 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](http://funretro.io/)). Tinha um pessoal que gostava de acessar [esse site](https://www.funretrospectives.com/) para aprender novos formatos de retrospectiva. 

### <a name="refinamento"></a>Refinamento :microscope:
:date: Antes do planning 
:hourglass: 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! :wink:


## 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