Cronograma das releases - duração

Primeiramente precisamos entender os motivos de criar datas de release. Podemos ter entrega de valor para os clientes de diferentes formas: durante toda a sprint ou na review. Acredito que ter os dois é melhor ainda! Os benefícios são muitos de ja na Review ter todas as histórias de Usuário em produção. A apresentação fica um espetáculo! Mas atingir este nível requer muitos pontos e o tamanho da organização influencia muito... sistema legado...diferentes times atuando no mesmo projeto...

O tempo para se chegar numa release é fixo? O tempo para se chegar numa release não precisa ser fixo, definir este ponto tem seus motivos específicos e não recomendo deixar fixo a menos que os riscos sejam maiores que os ganhos.

A duração das sprints deve ser fixa? No primeiro momento não precisa até porque definir se serão de 1, 2, 3 ou 4 semanas pode ser uma decisão precipitada ja que não temos dados para afirmar qual é o tempo mais adequado. Se o time ja tem um histórico e entende que por exemplo trabalhar com sprints de 2 semanas é o melhor cenário o ideal é não mudar depois. Mas nunca deixar de lembrar que a frequencia do feedback é uma percepção interessante em cada caso e cenário. Precisamos conhecer nossos clientes e suas disponibilidades. Estas podem ser informações que podem fazer a duração da sprint mudar para melhor atender ambas as partes.

Usar o tempo máximo de 4 semanas para uma sprint e release de 2 sprints pode ser feito. Mas não recomendo de forma alguma. Trabalhei com sistemas legados de algumas das maiores empresas do Brasil e inclusive com o SAP (Alemão) e acho muito arriscado usar estes tempos. Por mais complexo que seja o cenário o PO deve ser capaz de continuar fatiando em partes menores e com certeza conseguirão entregar resultados de valor em uma periodicidade mais interessante até mesmo para corrigirem o curso mais agilmente.