A Sprint – O Coração do Scrum; Confira

Sprint significa “arrancada” em inglês, referência ao treino de corrida intervalado, com corridas rápidas e constantes, com velocidade (pace) alta do início até o final, mas com tempo de recuperação maior. Fazendo mais ou menos um paralelo, no Scrum o time trabalha na Sprint de curto prazo (de 1 a 4 semanas), com velocidade rápida e constante adaptada ao desempenho do time até o final do Projeto.

A ideia principal da Sprint é: maior velocidade para desenvolver uma grande quantidade de entregas em menor prazo possível, levando em consideração a velocidade do time.

O Guia Scum (2020), considera que:

“Sprints são o coração do Scrum, onde ideias são transformadas em valor. São eventos de duração fixa de um mês ou menos para criar consistência. Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior.

Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints”.

Além de ser considerado como coração do Scrum a Sprint é um container para outros eventos, ou seja, dentro da Sprint estão contidos todos os eventos: o Planejamento da Sprint, a Reunião Diária, a Revisão da Sprint e a Retrospectiva da Sprint, além do tempo de desenvolvimento dos trabalhos. Os prazos de execução destes devem ser considerados quando da definição da duração das Sprints (de 1 a 4 semanas). Não é recomendado, mas a duração da Sprint pode ser alterada no decorrer do projeto após negociação entre o(a) Dono(a) do Produto (PO) e os Desenvolvedores.

🎯 A Sprint é um evento timeboxed de 1 a 4 semanas. Quem define a duração de cada Sprint é o Time Scrum, baseando-se em experiências passadas, em análise criteriosas do Backlog do Produto e levando em consideração as características do projeto.

Ainda de acordo com o Guia Scrum (2020):

Durante a Sprint:

Nenhuma mudança é feita que coloque em risco a meta da Sprint;

A qualidade não diminui;

O Product Backlog é refinado conforme necessário; e,

O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido”.

Durante a Sprint, a qualidade não pode ser reduzida e nenhuma mudança é aprovada se colocar a Meta da Sprint em risco. O Backlog do Produto é continuamente refinado e todas as mudanças são bem-vindas, mas deverão ser imediatamente analisadas pelo Time Scrum. A medida que as mudanças forem sendo aprovadas, devem ser priorizadas e incluídas no Backlog do Produto. O escopo pode ser explicado e renegociado entre o(a) Dono(a) do Produto (PO), Cliente e os Desenvolvedores no decorrer do desenvolvimento.

🎯 Se durante a Sprint, um Desenvolvedor verificar que não será capaz de completar os itens previstos, deve convocar uma reunião com a presença do(a) PO para revisar e ajustar os itens do Backlog da Sprint.

Também, o trabalho a ser executado poderá terminar antes do previsto, se isso ocorrer poderão ser incluídos novos itens ao Backlog da Sprint que complemente o tempo remanescente. Por exemplo, em uma Sprint de 4 semanas, estavam previstos 4 incrementos valiosos do produto, mas durante a execução percebeu-se que o uso de uma tecnologia nova acelerou o desenvolvimento, por isso, em 3 semanas os 4 incrementos previstos ficaram prontos. Neste caso, os Desenvolvedores, poderão solicitar que 1 ou mais Itens do Backlog do Produto (PBI) sejam adicionados a atual Sprint, desde que o prazo previsto para os concluir seja de no máximo mais 1 semana, que é prazo para o término da Sprint.

🎯 O objetivo de uma Sprint é produzir um incremento do produto funcional, valioso e útil.

🎯 Em caso de existirem múltiplos Times Scrum trabalhando no projeto, o Guia Scrum não determina que o tamanho das Sprints sejam todas de mesma duração.

A seguir é apresentado uma nuvem de tópicos em relação a Sprint:

De acordo com o Guia Scrum (2020),

Sprints permitem previsibilidade, garantindo a inspeção e adaptação do progresso em direção a uma meta do Produto ao menos uma vez por mês. Quando o horizonte de uma Sprint é muito longo, a meta da Sprint pode se tornar inválida, a complexidade pode aumentar e o risco pode aumentar. Sprints mais curtas podem ser empregados para gerar mais ciclos de aprendizagem e limitar os riscos de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado um projeto curto.”

🎯 Cada Sprint pode ser considerado um projeto de curto prazo.

As Sprints são limitadas a um mês, pois permitem a inspeção e adaptação em direção ao objetivo, limitado ao risco de custo de um mês corrido, caso algo não saia conforme planejado e seja necessário uma mudança de escopo muito grande ou cancelamento da Sprint.

🎯 A duração da Sprint deve ser de no máximo um mês, curta o suficiente para manter o risco comercial dentro do limite organizacional aceitável e curta o suficiente para poder sincronizar o trabalho de desenvolvimento com outros eventos de negócio.

Cancelamento e Encerramento da Sprint

A Sprint pode ser cancelada antes do timeboxed da Sprint terminar. Tão somente o(a) Dono(a) do Produto (PO) pode cancelar a Sprint. A Sprint poderá ser cancelada se a Meta da Sprint não fizer mais sentido. Por exemplo, se as condições do mercado ou de tecnologia mudaram, inviabilizando o projeto.

Cancelamentos de Sprints consome recursos, geralmente são traumáticos para o Time Scrum, porém são raros de ocorrer. Quando ocorre o cancelamento da Sprint todos os itens do Backlog da Sprint incompletos são analisados, estimados novamente e incluídos de volta no Backlog do Produto.

🎯 A Sprint é encerrada quando o tempo dela expira. Quando a Sprint se encerra, imediatamente inicia a próxima, não existe intervalo entre elas.

Monitorando o Progresso da Sprint

Em qualquer ponto do tempo, o total do trabalho restante para alcançar a Meta do Produto pode ser somado. O(A) Dono(a) do Produto (PO) acompanha o total do trabalho restante pelo menos a cada reunião de Revisão da Sprint. O(A) Dono(a) do Produto (PO) compara este valor com o trabalho restante demonstrado nas Revisões das Sprints anteriores para avaliar o progresso. Esta informação deve ser transparente para todas as partes interessadas do projeto.

Os Desenvolvedores monitoram o total do trabalho restante em cada Reunião Diária para projetar a probabilidade de alcançar a Meta da Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, os Desenvolvedores podem gerenciar o seu progresso.

O Time Scrum deve inspecionar frequentemente os artefatos do Scrum e se estão progredindo em direção as metas, desde que não atrapalhe o progresso do trabalho.

Várias práticas para prever tendências são usadas para mostrar o progresso, tais como burndowns, burnups, ou fluxos cumulativos. Estas ferramentas têm se provado muito úteis no mundo ágil.

O Ciclo de Vida da Sprint

A sequência dos eventos Planejamento da Sprint, Reunião Diária, Revisão da Sprint e Retrospectiva da Sprint deve ocorrer para que o ciclo de vida de uma Sprint esteja completo. Descumprir esta sequência pode limitar os benefícios do Scrum.

Outros eventos podem ser acoplados, como Reunião de Refinamento e Reunião 1×1. Abaixo apresento sugestão de ciclo de vida de uma Sprint de 2 semanas:

Periodicidade	Evento
Primeiro dia	Planejamento da Sprint
Diariamente	Reunião Diária
	Desenvolvimento, revisão de estimativas e decomposição das Histórias de Usuário em subtarefas
	Atualização dos Radiadores de Informação
Semanalmente	Reunião de Refinamento do Backlog
Quinzenalmente	Reunião 1×1 (one-to-one meeting)
Último dia da Sprint	Revisão da Sprint
Último dia da Sprint	Retrospectiva da Sprint.

Ciclo sugerido de uma Sprint:

🎯 Não é normal existir Sprints específicas para testes ou para sanar débitos técnicos. Quando o incremento é entregue, ele deve ser utilizável, ou seja, passou por todos os testes e atendeu a Definição de Pronto. Então, não deveria ter nada mais a complementar ou consertar. Usualmente os débitos técnicos são transformados em PBI para serem sanados nas próximas Sprints, levando em consideração a sua criticidade.

A Reunião de Refinamento não é formalizada pelo Guia Scrum, porém, é uma boa prática, onde o(a) PO e Desenvolvedores colaboram para garantir que o Backlog do Produto esteja priorizado, estimado e os seus detalhes atualizados. Isso acelera o próximo Planejamento da Sprint. Normalmente uma reunião semanal de 45 minutos atende ao propósito, mas cabe ao Time Scrum definir sua periodicidade e tempo, mas que não deve ocupar mais de 10% do esforço total dos Desenvolvedores durante a Sprint.

🎯 O Refinamento do Backlog do Produto não deve ocupar mais de 10% do esforço total dos Desenvolvedores durante a Sprint.

Bem como o refinamento, a reunião 1×1 (one-to-one meeting) entre Scrum Master e Desenvolvedores não é definida no Guia Scrum, mas é necessária para que o(a) Scrum Master conheça os anseios e até os problemas encontrados pelos Desenvolvedores que podem estar influenciando negativamente no eficácia do time. A sua periodicidade deve ser definida pelo(a) Scrum Master e considerada no meio de alguma Sprint.

Se quiser se aprofundar no Scrum, compre o livro Scrum Path+ : Seu caminho para agilidade, ou faça o curso Completo de Scrum. Escolha através dos botões abaixo:

Livro SP+

Curso SP+