Scrum: Sprint curto VS longo

Estávamos tentando descobrir a duração ideal do sprint para o nosso projeto. Depois de trabalhar em 3 semanas, pensamos que cortar o sprint para 2 semanas proporcionaria uma velocidade melhor.

As vantagens eram claras: ciclo de feedback mais curto, pequenas histórias (com valor para o usuário) e assim por diante. Por outro lado, existem muitas desvantagens, como cerimônias (planejamento retrospectivo) e outras que não produzimos e agora acontecem com mais frequência.

Fiquei me perguntando como, para uma nova equipe, podemos decidir sobre a duração ideal do sprint?

Eu acho que você está olhando para trás um pouco. A velocidade é um efeito posterior do trabalho que sua equipe está realizando. É não um fator causal - ie. é algo que você mede e não é algo que você pode ajustar diretamente.

Esta explicação da velocidade tem um detalhe relevante para sua pergunta.

A maneira mais simples de definir velocidade é: o número ou histórias de usuários que uma equipe / projeto pode fazer em um sprint

E, por essa definição, um sprint mais longo significa mais tempo para o desenvolvimento por sprint e, portanto, um número de velocidade maior.

A velocidade relativa entre um sprint de 2 ou 3 semanas é uma questão um pouco diferente. A sobrecarga das cerimônias do projeto pode afetar o quanto você pode fazer, porque há menos tempo geral disponível. Considere esse cálculo como uma maneira de identificar as horas de desenvolvimento disponíveis em um sprint.

DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs

CeremonyOverheadgeralmente é fixo. Diminua seu DaysInSprinttamanho e veja como você terá menos tempo disponível para desenvolvimento durante esse sprint. Usando um exemplo simples de 1 dev, aqui estão os números para alguns comprimentos de sprint.

1 semana:
((8 * 5) - 4) * .8 = 28,8 horas ou 5,76 horas por dia.
2 semanas:
((8 * 10) - 4) * .8 = 60,8 horas ou 6,08 horas por dia.
3 semanas:
((8 * 15) - 4) * .8 = 92,8 horas ou 6,18 horas por dia.

A resposta "óbvia" é que os sprints mais longos são melhores. O problema com a resposta óbvia é que ela ignora o impacto benéfico dos ciclos de feedback. Tempere pensamentos sobre esse cálculo com uma perspectiva geral sobre o que o Agile deve trazer para o processo de desenvolvimento.

Suspeito que seu principal problema é que suas histórias de usuário não estão tão definidas quanto poderiam ser. Essa falta de compreensão do que é necessário é o verdadeiro impedimento para a realização do trabalho.

Por outro lado, existem muitas desvantagens, como cerimônias (planejamento, retrospectiva) e assim por diante.

Esta é uma grande bandeira vermelha. Se você o vê como cerimônia, e não como veículo essencial que serve ao processo de trabalho e à sua melhoria, provavelmente trabalhar nele tem mais ganho do que mexer no comprimento do sprint.

O processo está nas suas mãos (ou seja, na equipe). Você deve perseguir as idéias mais bonitas, se precisar experimentar e se ajustar. Estávamos fazendo 2 semanas e depois mudamos para 3 semanas e funcionou melhor. Mas, às vezes, apenas defina o comprimento com base na estimativa do escopo. Sim, estou ciente da idéia de "comprimento igual", mas não é um dogma e pode não se encaixar em algum projeto da vida real. E ter um objetivo de sprint claro e evidente pode servir melhor.

O comprimento adequado não é realmente algo que possa ser deduzido de fora. Você está lá para conhecer os fatores relevantes. No planejamento, você pode começar com "ok, o que podemos fazer nas próximas X semanas". Ou então "qual seria o próximo incremento sensível". De qualquer forma, planejar o último é bom; então, observe que horas levaria. E parte disso em um ou mais sprints.

Você decide. Experimente os dois, veja o que funciona. Use isso.

O melhor 'sprint' ágil que já usei foi de 6 semanas. Fizemos muitas coisas - mas só precisávamos entregar ao cliente dentro desse prazo. Não usamos tarefas, preferindo trabalhar ao estilo de trabalho da história do usuário.

Depende do que você descreve uma "nova equipe".

De fato, a velocidade de uma equipe depende de muitos parâmetros entre muitos (ex .: juniores ?, seniores ?, recém-chegados ?, tensões entre os membros da equipe ?, etc.).

Portanto, o comprimento "ideal" do sprint também está vinculado a esses parâmetros.

De qualquer forma, não existe uma solução pronta para isso, a única maneira é testá-la com a própria equipe e também levar em consideração o melhor ajuste médio para todos os membros da equipe.

Eu questiono sua sugestão de um "ciclo de feedback mais curto". Sua equipe deve trabalhar com seus clientes diariamente - o feedback não deve esperar pela Revisão e Retrospectiva da Sprint. Teste, codifique, projete e obtenha feedback imediatamente .

Pessoalmente, gosto do sprint de três semanas, porque a semana do meio permite à equipe algum tempo de "fluxo". Ou seja, sempre há muito tempo acelerando a primeira semana (aprendendo o que diabos essas novas histórias significam) e alguns terminando a última (preparando a revisão). Uma semana no meio para simplesmente produzir software de trabalho é uma coisa muito boa de se ter.

Levando essa lógica adiante, as corridas de quatro semanas fariam ainda mais sentido. No entanto, o senso de urgência pode ser perdido se você começar a estender seus sprints. Além disso, existe realmente um pedaço relativamente pequeno de informação que uma pessoa ou equipe pode captar e reter em seu pensamento consciente ao mesmo tempo - quanto mais longo o sprint, mais coisas você está tentando focar, o que pode tornar as coisas mais difíceis do que Mais fácil. Além disso, é mais difícil julgar quais fatores externos surgirão se você estender as coisas muito longe.

Como você perguntou sobre uma nova equipe, gostaria de acrescentar algumas idéias. Trabalho com Scrum e outros métodos Agile há mais de 15 anos e agora sempre recomendo que as novas equipes comecem com Sprints de uma semana. Existem três razões críticas para isso:

• Sprints mais curtos ajudam as equipes a alcançar um estado de alto desempenho mais rapidamente. Long Sprints geralmente significam que são necessários 18 meses a dois anos para chegar a esse estado. Sprints curtos de uma semana ajudam a equipe a atingir esse estado de alto desempenho em apenas dois ou três meses. É claro que outras coisas também precisam estar em vigor para obter alto desempenho (consulte "A sabedoria das equipes", de Katzenbach e Smith).
• Como outros já mencionaram, um Sprint mais curto aumenta o ciclo de feedback. Uma Sprint de uma semana parece ser ideal para a maioria das equipes que desenvolvem software ou desenvolvimento de produtos. O feedback deve ocorrer principalmente durante a Sprint Review, que deve substituir o seu processo UAT tradicional.
• Por fim, Sprints mais curtos pressionam sua equipe a lidar com obstáculos organizacionais à entrega frequente. Essa pressão é muito desconfortável no início, mas é essencial para melhorar seus processos gerais de desenvolvimento, incluindo planejamento, conformidade, lançamentos, etc.

Eu escrevi um artigo chamado 21 Dicas para escolher um comprimento de sprint que possa ser interessante.

As cerimônias têm um objetivo - quando reconhecemos o objetivo, percebemos que elas não estão sobrecarregadas, mas agregam valor.

Planejamento - não apenas sobre o compromisso de trabalhar, mas também sobre como trabalhar com seus colegas de equipe. Quando as pessoas reclamam da falta de colaboração em sua equipe Scrum, eu gosto de ver o seu Sprint Planning como parte do problema

Revisão - colete feedback do cliente sobre o que estamos construindo e ainda é relevante etc. Também atua como uma verificação de qualidade.

Retrospectiva - melhore a maneira como trabalhamos juntos como uma equipe.

Quando nos esforçamos para honrar o objetivo mais profundo, o problema de sobrecarga geralmente desaparece. Como foi observado nos comentários originais da pergunta, as cerimônias geralmente são dimensionadas linearmente.

Se você precisar de mais informações sobre o assunto, tenho um artigo: Escolhendo um comprimento de sprint