3.6 Duração da Sprint

O Scrum define somente a duração máxima de uma Sprint, ou seja, não mais de quatro semanas. Esta duração máxima assegura que ninguém é privado do direito para adaptar os planos futuros para o produto pelo menos a cada 4 semanas. Além disso, a equipe não fica trancada num contêiner por muito tempo, correndo o risco de perder o controle sobre um mundo em mudança.

A duração da Sprint mantém um equilíbrio entre retenção de foco para obter uma quantidade substancial de trabalho pronto e adaptabilidade oportunista, pesados contra outros fatores, como incertezas tecnológicas e oportunidades de aprendizado.

Em um processo empírico como Scrum, os objetivos de controle são apresentados ao sistema e, por meio de um ciclo de feedback fechado, os resultados são regularmente inspecionados contra estes objetivos para adaptar materiais de trabalho, tarefas e processos. Inspetores qualificados, os papéis previstos no Scrum, realizam inspeções em uma frequência apropriada, de modo que o foco e o tempo exigidos para criar um resultado valioso são balanceados junto ao risco de permitir uma variação demasiada na saída criada.

Além da transparência, a frequência é um fator importante no empirismo. Os eventos do Scrum determinam a frequência das inspeções e adaptações, com o Sprint sendo um evento contêiner, o ciclo de feedback externo que envolve o ciclo de feedback da Daily Scrum, e os ciclos de feedback das práticas de desenvolvimento aplicadas na Sprint.

Há uma clara tendência a passar a usar Sprints mais curtas. Embora não seja uma obrigação formal, Sprints de uma semana parecem um mínimo aceitável.

Vamos dar uma olhada nisso presumindo que um time faz Sprints de um dia.

Todos os eventos Scrum, como oportunidades para inspecionar e adaptar, ocorrem na duração de um dia, e são organizados numa frequência muito alta. Na verdade, ao tentar realizar todos os eventos, a equipe passa uma quantidade de tempo razoável inspecionando e adaptando o menor dos pacotes de trabalho. A frequência fica no caminho da produção de valor.

O perigo é ainda maior pois o time irá se focar meramente no seu trabalho diário e progresso, perdendo de vista o panorama geral. Eles não terão tempo para inspecionar e adaptar o processo geral, ou provar maneiras de melhorar a qualidade ou se conectar a metas e objetivos abrangentes. Eles apenas tentarão empurrar mais produto da porta pra fora, todos os dias.

A duração da Sprint também determina a frequência na qual o Product Owner e o Development Team consultam os stakeholders sobre uma versão funcionando do produto. A finalidade é compartilhar toda informação necessária para ajudar o Product Owner a tomar decisões sobre o futuro do produto. No caso de Sprints de um dia, será mais difícil conseguir o apoio dos stakeholders, e também a permissão para captar e adaptar às mudanças corporativas, de mercado e estratégicas.

A duração da Sprint deve levar em conta o risco de perder uma oportunidade de negócio porque as Sprints são demasiadas longas. Se seu negócio é tão volátil que você arrisca perder oportunidades gastando mais de um dia no contêiner de uma Sprint, por favor faça Sprints de um dia. Mas tenha cuidado para não queimar os mecanismos de inspeção numa frequência tão alta.

Evite que o Scrum se transforme num novo nome para a velha corrida dos ratos, onde não há lugar para humanização no local de trabalho. Organize o trabalho de forma que seja sustentável, indefinidamente.

OceanofPDF.com