Ash Tengshe wrote:
> Really there are two forces that determine the sprint length
>
> <--Force that tries to elongate--> Getting to "Done" in a sprint and
> how hard it is in certain environments to complete SDLC steps in 2
> weeks vs. 4
>
> -->Force that tries to shorten<-- The rule of no scope changes in the
> active Sprint. This means that the shorter they are the more
> likelihood of low changes. This depends also on the dynamism of the
> environment the team is working in

To me, there are at least three more forces at work that shorten the
sprint length:

- Closure. A sprint end feels good, because you finished another sprint
of work. It should be a moment of celebration and pride. Having it more
often can be quite motivating.

- Feedback. The end of an iteration is a good place to reflect on the
work we have done. Did we estimate well enough? Did we understand the
backlog items? Did we work on the right backlog items? Did we totally
mess up the sprint? What do we want to do differently in the next
sprint? (Kent Beck once asked when being asked for the right iteration
length for an XP project "how much work can you effort to have wasted?")

- ROI. A sprint end is a good point to assess whether to put the current
system into production. If you can do that two weeks earlier, you get
better return on investment.

Cheers, Ilja