… realmente fiquei um pouco confuso quando li “arcar com o prejuízo” para aumentar o sprint, pois dessa forma não estariamos respeitando o timebox!!!

E como vc mesmo disse isso seria o início do fim!!!!
heheheheh!!!

Valeu pelas dicas.

[]’s
Claudio

Ainda sobre o mesmo assunto do comentário anterior, recomendo a leitura desse artigo do Patrick Kua entitulado “Why timeboxing is important”: http://www.thekua.com/atwork/2008/07/03/why-timeboxing-is-important/

[ ]s, gc

Isso NUNCA pode acontecer!!! Aumentar a duração de um Sprint ou iteração não é em hipótese alguma uma decisão válida. Ninguém pode decidir isso, nem o time e nem o P.O.

Não respeitar o timebox é uma violação básica de qualquer metodologia ágil:

“The important thing about time boxing is that the dates are not flexible, but the deliverables are. Without time boxing, when the deliverables cannot be delivered, the deadline slips. With time boxing, the deadline is fixed, and the deliverables are adjusted (hopefully in agreement with the customer/user).” — http://en.wikipedia.org/wiki/Time_boxing

Fora isso, as métricas de velocidade do time são afetadas, o planejamento de entregas de todos os sprints para frente são afetados e você certamente começará a ter Sprints totalmente em funcão das funcionalidades, que poderão durar de dois dias a dois meses ou dois anos. Em outras palavras, isso é o início do fim.

[ ]s, gc

É difícil dizer uma regra exata. A avaliação é totalmente subjetiva e deve ser feita caso a caso pelo time. Inclusive seria perfeitamente possível que dois times diferentes tomassem decisões diferentes com esses mesmos números, baseando-se em outros fatores diversos.

[ ]s, gc

Guilherme, e se por exemplo se perceber que esse monstro apenas trará um adicional de 2 a 3 dias no Sprint ?

O que fazer?

Cancelar o sprint ou arcar com o tempo excedido?

Fabio Nascimento