A fixed iteration length enables a team to establish a
development and delivery rhythm. It facilitates improved estimation
accuracy allowing the team to obtain a tangible feel for what they
can deliver within an iteration. Rhythm is an important factor,
which helps a team achieve a sustained pace. In a 2-week iteration,
the team get used to planning for 0.5 days at the start of an
iteration, developing for 9 days with increasing intensity, and
then reviewing the functionality with the
customer for 0.5 days at the end of an iteration. This
cycle provides a consistent environment for the team.
I've worked in organisations where iteration lengths were varied
depending on the mandatory functionality selected for an iteration.
There's nothing wrong with this practice per se, but it does
require the team to be more conscious of the varying timelines and
this results in questions like "when is the end of this iteration?"
and "is this the last week of this iteration?". Conscious is the
important word here. An established rhythm drives the team,
subconsciously, along a fixed timeline enabling them to concentrate
on developing the functionality. A varying iteration length is
simply another variable to think about and administer - and this
introduces some risk and management overhead. Ideally you want to
keep as many variables as possible constant.
Tuesday, 26 October 2004
Fixed iteration length
Posted by Simon Baker - Permalink
