Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Tempo para planejamento de um sprint

Boa tarde André! Não entendi muito bem sobre a estimativa do planejamento, no módulo 5 fala-se em (1/2) 1 hora sprint/semana. No scrum fala-se em 8 horas para uma sprint de 1 mês. Pensando em uma sprint de 1 semana, teríamos 2 horas para mesma. Estou certo no meu raciocínio? Ou há outro sentido para o que foi dito no módulo?

4 respostas

Boa tarde!

Alguém poderia responder ao meu questionamento?

Grato, Gillian Lopes

oi, Gillian.

A sprint planning é um timebox de 5% do tempo da sprint.

Então, se a sprint é de um mês, a planning deve durar "no máximo" 8 horas, e proporcionalmente menos para sprints de menor tamanho. Então, você está correto:

  • Sprint de 4 semanas: 8 horas de planning;

  • Sprint de 3 semanas: 6 horas de planning;

  • Sprint de 2 semanas: 4 horas de planning;

  • Sprint 1 de semana : 2 horas de planning;

Observar que este é o limite máximo, mas não significa que deva durar todo este tempo.

Não sei por qual motivo o instrutor falou desta forma.

Em todo caso, é só uma aproximação. Enquanto alguns autores afirmam que este é um limite máximo que não deve jamais ser extrapolado, outros enfatizam o "aproximadamente", sugerindo que pode ser menos ou mais que o tempo. Por isso que coloquei "no máximo" entre aspas.

Na prática, não existe imposição. Se por acaso não conseguir realizar a planning dentro do prazo sugerido, não faz sentido a mesma ser interrompida abruptamente tendo deixado várias pendências para se resolver. Fica como lição aprendida para que na próxima reunião já se tenha feito um planejamento prévio da mesma para que não demore tanto. Seja por meio da intervenção do Scrum Master, por exemplo, para que a reunião não se perca com outros assuntos), seja promovendo grooming durante a sprint atual, antes da planning da próxima sprint.

Bom dia Jorge!

Agradeço pelos esclarecimentos e concordo que caso ainda se tenha alguns assuntos importantes, a reunião deve-se prolongar um pouco mais para que estes assuntos sejam finalizados. E com certeza uma lição aprendida, pois nestes eventos do scrum é muito importante seguir os time-box.

PS: Talvez seja interessante alterar essa parte do material, ficou bem confuso.

Atte., Gillian Lopes

solução!

Sim. Como é na planning que se esclarece o que será feito (meta) e as dúvidas devem ser dirimidas (lembrar dos 3C's: cartão, comunicação e confirmação), o prejuízo de interromper uma planning é maior do que finalizá-la com atraso. Ou seja, toda a sprint pode ser comprometida por não se saber o que fazer. Então vale a pena arcar com o prejuízo de uma planning mais prolongada.

Sobre o tempo da planning deve-se, inclusive, considerar a quantidade de horas de trabalho da equipe.

Pois, dependendo da empresa, a carga horária pode ser de 8 horas, em outras pode ser menos (meio período, por exemplo). Além disso, há empresas que trabalham no sábado, outras não. Mais um motivo para não se apegar tanto a estes números (ou pelo menos considerar os 5% do tempo total).

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software