O que acontece em uma Sprint e quando?

A implementação bem-sucedida do Scrum envolve uma série de cerimônias importantes. Entre elas estão o Sprint Planning, o Sprint Review, o Daily Scrum, a Sprint Retrospective, entre outras.

Frequentemente surgem dúvidas sobre quem deve participar de quais cerimônias do Scrum, quando elas acontecem, quanto tempo devem durar, qual é o objetivo de cada cerimônia, etc.

Neste artigo, vamos esclarecer essas dúvidas:

O Sprint Planning

Quando o Sprint começa, o Sprint Planning também é realizado. Ele marca oficialmente o início do Sprint.

Todo o time Scrum participa do Sprint Planning ; ou seja, tanto o time de desenvolvimento quanto o Scrum Master e o Product Owner. Em casos raros, outras pessoas também podem participar deste evento, se o Product Owner e o time de desenvolvimento considerarem apropriado. Por exemplo, se no próximo Sprint for desenvolvida uma funcionalidade que é melhor explicada por um especialista no assunto (que não seja o Product Owner), pode ser útil que essa pessoa esteja presente no Planning. Na maioria dos casos, porém, é mais sensato que essas discussões aconteçam fora da reunião de Planning propriamente dita.

A duração do Sprint Planning é proporcional à duração do Sprint. Para um Sprint de quatro semanas, o Planning não deve durar mais que oito horas; para um Sprint de uma semana, não mais que duas horas – ou seja, no máximo duas horas por semana de Sprint.

Essa limitação de duração máxima de uma reunião também é chamada de Time Boxing. Eu recomendo que os times tentem concluir o Sprint Planning em aproximadamente metade do Time Box máximo permitido.

Como input para o Sprint Planning, o Scrum Master traz informações sobre a Velocity (velocidade de trabalho) média e atual. O Product Owner traz o Product Backlog ou pelo menos os itens do Backlog com maior prioridade para o Planning. Em alguns times, o Product Owner também já apresenta no Planning uma meta de Sprint preliminar, que pode ser refinada junto com o time durante o Planning.

O resultado do Sprint Planning é um time mais informado e melhor preparado para o trabalho que está por vir. Outros resultados do Planning são o Sprint Backlog e uma meta de Sprint criada em conjunto.

Daily Scrum / Daily Standup

O Daily Scrum – também conhecido como Daily Standup – é uma cerimônia curta que acontece diariamente, onde os membros do time se sincronizam em relação ao seu trabalho. Com os Daily Scrums, você garante que as pessoas certas estejam trabalhando nas coisas certas, no momento certo.

Todos os dias, cada membro do time responde às seguintes três perguntas:

1. O que eu fiz ontem para alcançar o objetivo da Sprint?

2. O que vou fazer hoje para alcançar o objetivo da Sprint?

3. Tenho impedimentos/problemas que estão me atrapalhando? Se sim, quais?

Essas perguntas podem ser formuladas de diversas maneiras. Algumas equipes preferem, por exemplo, descrever o que alcançaram em vez do que fizeram.

Participantes devem ser o ScrumMaster, a equipe de desenvolvimento e, na minha opinião, também o Product Owner.

Na comunidade Scrum existem algumas discussões sobre se o Product Owner deve ou não participar do Daily Scrum. Permitir que o Product Owner não participe do Daily Standup pode afastá-lo demais da equipe. Um sentimento de "nós contra eles" já existe em muitas organizações. Não consigo imaginar por que uma Equipe Scrum ou seu Product Owner gostaria de reforçar ainda mais essa atitude negativa.

Os Daily Scrums são limitados a uma duração máxima de 15 minutos. O objetivo do Daily Scrum é uma breve sincronização da equipe. Diferente do Sprint Planning, aqui não recomendo terminar na metade do tempo previsto. Para a maioria das equipes, 5-7 minutos simplesmente não são suficientes para abordar problemas reais ou entender quais trabalhos foram concluídos. Quando os Daily Scrums são encurtados demais, rapidamente se tornam rotina com declarações como "Ontem fiz XY. Hoje vou fazer isso e aquilo. Não tenho impedimentos."

Não há resultados formais dos Daily Scrums, além da melhor coordenação dos trabalhos na equipe de desenvolvimento.

Revisão do Sprint

A Sprint Review acontece no último dia do Sprint. Product Owner, ScrumMaster e Time de Desenvolvimento devem estar presentes, assim como os respectivos Stakeholders. Quais stakeholders devem participar varia de Sprint para Sprint e depende do que foi entregue no Sprint.

A Sprint Review tem um Time Box de no máximo quatro horas para um Sprint de quatro semanas. Proporcionalmente, os time boxes são mais curtos para Sprints mais curtos, por exemplo, uma hora para um Sprint de uma semana.

Na Sprint Review devem ser mostrados todos os Product Backlog Items que atendem à Definition of Done. Isso significa que não são mostrados trabalhos que ainda estão em andamento, ou seja, que ainda não foram finalizados. Às vezes, é claro, pode fazer sentido abrir uma exceção a essa regra.

A demonstração de funcionalidades finalizadas é a atividade central de uma Sprint Review típica. A maioria dos times também reserva tempo para discutir progressos e eventuais problemas.

O objetivo da Review é obter feedback sobre o que foi desenvolvido durante o Sprint. O Product Owner recebe todo o feedback e pode, com base nele, ajustar o Product Backlog se necessário. O resultado de uma Sprint Review é, portanto, um Product Backlog revisado.

Retrospectiva da Sprint

Na Sprint Retrospective os membros da equipe têm a oportunidade de refletir sobre como podem melhorar sua forma de trabalhar. Isso pode significar, por exemplo, que querem mudar a maneira como implementam o Scrum e então ajustar a duração do Sprint. A Retrospectiva também pode abordar aspectos gerais da colaboração, como não marcar mais reuniões pela manhã ou definir quais assuntos podem ser discutidos no Slack e quais devem ser resolvidos em uma conversa pessoal.

Na Sprint Retrospective deve participar toda a equipe – ou seja, a equipe de desenvolvimento, o ScrumMaster e o Product Owner. Qualquer outra coisa só levaria a uma divisão na equipe. Uma boa equipe ágil deve evitar qualquer comportamento que leve a uma mentalidade de "nós-contra-eles".

Além da vontade de melhorar, a Sprint Retrospective não precisa de nenhum outro input. O resultado da Retrospectiva deve ser uma lista de mudanças ou sugestões de melhoria que a equipe quer implementar.

O timebox para uma Retrospectiva é de no máximo 3 horas. De vez em quando pode demorar um pouco mais, mas na maioria dos casos as equipes terminam em menos de uma hora.

Refinamento do Product Backlog

O Product Backlog Refinement serve para garantir que os itens no topo do Backlog estejam prontos para o próximo Sprint. Isso pode significar adicionar detalhes a itens existentes, fazer estimativas, remover certos itens, reorganizar prioridades, dividir Backlog Items em itens menores ou criar novos itens.

Mesmo que o Refinement do Backlog seja necessário por si só, isso não significa que um time precise fazer isso como uma cerimônia oficial ou que precise ser feito em todo Sprint. A maioria dos times, no entanto, realiza reuniões regulares de Backlog Refinement, tipicamente uma vez por Sprint ou por semana.

Uma boa diretriz é que um time não deve gastar mais de 10% do seu tempo total disponível com o Backlog Refinement – tanto na reunião em si quanto nas discussões posteriores que surgem dela.

Na maioria dos times, participam das reuniões todos os membros do Time de Desenvolvimento, bem como o Product Owner e o ScrumMaster. A menos que um time esteja estimando os Product Backlog Items em suas reuniões de Refinement, acredito que cerca de metade a dois terços do esforço de desenvolvimento são suficientes, e assim a reunião pode ser mantida o mais curta possível para o time.

A única coisa que precisa ser trazida para o Refinement são os itens do topo do Product Backlog. Os resultados do Refinement são Product Backlog Items menores, que são mais adequados para o próximo Sprint, além de uma melhor compreensão de alguns Product Backlog Items.

Avaliação do Backlog

Como mencionado acima, muitas equipes já estimam seus itens do Product Backlog durante a reunião de Refinamento. Essa é a situação ideal e, se possível, toda a equipe de desenvolvimento participa do Refinamento do Backlog.

Se apenas parte da equipe participa do Refinamento, os membros da equipe se reúnem uma vez por Sprint para estimar todos os novos trabalhos para os quais o Product Owner precisa de uma estimativa.

Na maioria das equipes, essas reuniões de estimativa devem ser bem curtas. As equipes não devem criar muitos novos itens do Product Backlog, nem receber uma avalanche de novos itens externos. Os trabalhos a serem estimados devem ser muito importantes ou itens novos ou existentes que foram divididos para se encaixarem melhor no Sprint seguinte.

Eu gosto de realizar a estimativa do Product Backlog logo após uma Daily Scrum e alguns dias antes do final do Sprint. Isso é tarde o suficiente para que a maioria dos novos itens já tenha sido identificada, e cedo o suficiente para o Product Owner poder ajustar a priorização com base nas novas informações das estimativas.

Eu não recomendo estimar os itens durante o Sprint Planning. Nesse momento, é tarde demais para o Product Owner ajustar a priorização com base nas estimativas. Além disso, isso faz com que os membros da equipe gastem mais tempo com as estimativas do que deveriam. Portanto, não faça a estimativa dos itens do Product Backlog durante o Sprint Planning.

Priorização

Antes de um novo Sprint começar, o Product Owner garante que todos os itens no topo do Product Backlog foram priorizados. Segundo o Oxford American Dictionary, priorizar significa: "Organizar tarefas, problemas etc. em ordem de importância, para que se possa lidar primeiro com os mais importantes."

Isso significa que não basta dizer: "Todos são necessários." Ou como um Product Owner me disse uma vez: "Não se chamam requisitos à toa; eles são requeridos."

Na maioria dos casos, não haverá uma cerimônia oficial para a priorização. É mais algo que o Product Owner faz sozinho, após conversas com os stakeholders para esclarecer suas necessidades e desejos.

A priorização deve acontecer o mais tarde possível no Sprint, mas definitivamente deve estar concluída antes do próximo Sprint. Isso muitas vezes significa que ela é realizada em um dos dois últimos dias do Sprint.

A priorização normalmente não consome muito tempo, já que o Product Owner tipicamente faz os ajustes finos ao longo do Sprint com base em novos aprendizados, em vez de priorizar todo o backlog em detalhes desde o início.

As reuniões em um Sprint

Como você pode ver, existe uma série de cerimônias importantes no Scrum que devem ser realizadas com atenção. Esperamos que este artigo tenha dado a você uma visão geral melhor e ajudado a trazer mais clareza no dia a dia com seu Time Scrum. Se você quiser saber mais, nossos Treinamentos Scrum são exatamente o que você precisa.

Este artigo foi originalmente publicado no blog de Mike Cohn e foi traduzido por nós para o alemão.