The iteration is a fixed timebox. And the iteration review
provides an opportunity to seek acceptance from the customer. It
provides closure for the iteration, which can then be reflected
upon in a retrospective. To maintain rhythm, it's important that
the iteration review is held at the same time, on the last day of
the iteration. Don't delay or postpone it. Respect the timebox.
Obviously the aim is to get all the agreed user stories done in
the iteration so that they can be demonstrated in the iteration
review. But shit happens. What can you do?
Don't start a user story that cannot be finished in the iteration.
It's better to descope the user story from the iteration than to
partially complete it by the time of the iteration review. Always
obtain the customer's permission to descope the user story or talk
with the customer to see if it can be spilt into smaller user
stories, one of which can be done in the time remaining.
If it looks like a started user story can't be finished in time,
don't push to get it done. It's better to let a partially completed
user story
slop to the next iteration than to
risk delaying the iteration review. Leave it. Back out the code and
demonstrate only the completed user stories in the iteration
review. Don't count the partially completed user story towards your
velocity for the iteration.
Tuesday, 22 August 2006
Respect the iteration timebox
Posted by Simon Baker - Permalink
