O que perdemos ao escolher um mês de duração da Sprint, em vez de uma semana?

Eu entendo que perde em ter as entregas mais cedo e assim os feedbacks mais cedo como vc disse, porém se a sprint é de 1 mês é porque a funcionalidade que vai trazer maior valor para o cliente é esse que só cabe em 1 mês, que não tem como dividi-lá em entregas menores. Então uma coisa compensa a outra! E ai quanto mais cedo o cliente tiver essa funcionalidade, mas cedo ele poderá dar o feedback também, e qualquer alteração fica para as próximas sprints.

Compreendo perfeitamente o seu ponto, Amanda, e concordo. Mas, pelo que entendi do Scrum, nada impede que possamos ter, eventualmente, sprints durações diferentes em situações específicas e acordadas com o time e o cliente. Seguindo o seu exemplo, podermiamos trabalhar com sprints de 15 dias e, para esta entrega, devido a importancia e o fato de não conseguir dividir, aumentarmos o ciclo para 1 mês. Uma vez entregue, as seguintes poderiam voltar ao padrão estabelecido inicialmente.

Mas Pablo, ai vc tá falando que a equipe não sabe a capacidade que tem, que não sabe planejar. Lógico, nas primeiras sprints não tem muita noção, mas vão evoluindo com o tempo e na Retrospectiva levar o ponto para fazer um cálculo melhor nas próximas estimativas. E diferença de 15 dias é um erro muito grande, lembrando que vc pode ter sprints de 1, 2, 3 ou 4 semanas.

Se na estimativa foi visto que a funcionalidade que vai trazer mais valor precisa de uma sprint de 1 mês e não tem como quebrá-la em PBI menores, a sprint tem que ser de 1 mês. Pra que fazer uma sprint de 15 dias se vc sabe que não vai entregar em 15 dias? Até mesmo pq cada sprint tem todas as cerimônias do SCRUM. Vc vai fazer uma retrospectiva no 15o dia pra que? Pra confirmar q não conseguiu entregar?

Agora se a equipe conseguir entregar os itens do Sprint Backlog antes do fim da SPRINT, até onde eu entendo do SCRUM, há algumas alternativas para ocupar o restante dos dias até o termino da sprint. Vc pode pegar um item novo do backlog (q caiba dentro desse período que falta), fazer o refinamento das user stories da próxima sprint antes do planejamento delas (e ter o time todo disponível para fazer esse refinamento e mais tempo é um sonho), e principalmente ... pagar dívidas técnicas (que não deixa de ser um item novo do backlog).

Tem outras alternativas, mas se vc me falar que não tem esses problemas que citei acima e falta tempo pra fazê-las, quero trabalhar no seu time!!! :)

Olá Amanda.

Só pra reforçar, compreendo o seu ponto, e considero válido que esteja trazendo a toda a sua experiência para discussão. Assisti as aulas, até então, novamente para tentar entender melhor e contribuir da melhor forma.

Pelo meu entendimento do que escreveu, avalia, de todo o projeto, o tempo previsto para entregar funcionalidade com maior valor agregado e esse periodo é estabelecido como padrão para todas as sprints do projeto, correto? Perfeito. Entretanto, não muda o fato de com sprints maiores, as chances de feedback diminuem proporcionalmente (sendo objetivo com o questionamento inicial do tópico).

Gostaria de compreender (de forma objetiva) qual seria o problema de, ao estimarmos o projeto, conseguirmos padronizar os ciclos em períodos menores (onde temos maior frequência de feedback), e nesta mesma estimativa sabermos que existe um entregável que demandará um tempo maior para o desenvolvimento, e apenas este, em caráter eventual, ter sua sprint maior (e não ser quebrada em 2 sprints)?

Posso estar entendendo errado (pois estou reciclando os conhecimentos com este curso e, como aluno, obviamente, não sou dono da verdade), mas não vejo isto como uma falha de planejamento, e não está fora da metodologia em si.

Oi, Pablo.

Referente ao tempo das sprints, elas não são fixas. Vc pode considerar a sprint 1 como 2 semanas, ai na sprint 2, vcs viram que o item que traz mais valor é de 1 mês, ai a sprint 2 pode ser de 4 semanas, na próxima vc pode voltar a colocar com 2 semanas. Tudo depende do que o time combinar e o que o PO trazer que deve ser feito primeiro.

Desculpe se pareceu se estou brigando ou algo assim, não foi a minha intenção, foi mais pra mostrar que não precisa fazer 2 sprints de 15 dias se o item é maior que 15 dias. Eu acho q o ruído que ficou é q as prints não tem obrigação de serem todas do mesmo tamanho.

Para a pergunta que vc fez, o que entendo é na metodologia SCRUM as sprints são TIME-BOX, isso faz com que o time trabalhe em um determinado tempo. Não tem tempo de "postergar", dar desculpas de não entregar na data (qualquer coisa tem um tempo a mais ou não darem prioridade ao que mais precisa, a gente acaba se perdendo no tempo), ser objetivo dentro de um período que vc se comprometeu. Tem um tempo determinado para o planejamento, para as cerimônias, para a daily. Se o SBI não coube ali, vai para a próxima sprint. Fazendo do jeito que vc falou, pra mim, dá a impressão que não tem fim, que não tem time-box.

Em times que já tem no sangue o SCRUM, que seguem os itens, que conhecem profundamente o produto que estão fazendo (o desenvolvedor conhece até a regra de negocio), que estão entrosados e etc, eles podem "quebrar a regra", tem experiencia do que pode acontecer. As equipes que não são tão senior assim, eu não recomendo. Por exemplo, já participei de várias dailys que a equipe não passa pelo que precisa, e discutem detalhes técnicos durante a daily e ai de 15 min vai para 1h, sendo que essas discussões podem ser feitas a qualquer hora do dia, mas as pessoas esperam a daily para falar dos detalhes, confundem a daily com reunião de trabalho, e isso acontece principalmente pq não priorizaram o que precisava para chegar na daily é só dar o status.

Outra coisa q lembrei também da sua pergunta original, nem em todo fim de sprint o PO coloca o entregável em produção, pode ser que o MVP seja a entrega de várias sprints, então o feedback de produção pode ser mesmo que a equipe não tenha a cada 15 dias, mesmo entregando uma sprint a cada 15 ou N dias.