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.
Previous Topic
