Incomplete Stories at the Iteration Review Meeting

Imagine your iteration ends and 1-2 critical stories are close but not quite done. They are far enough along to be demoed, but still needs a few tweaks and haven't gone through testing. It is tempting to include these in the iteration review, isn’t it? After all, they are most of the way there, and the customer wants to see a return on their investment, right?

Before you go ahead with this, consider some of these downsides:

• Precedence – The iteration review meeting is a line in the sand – did you finish your stories or not? Once you open the door to half-baked stories, you set a precedence that a story doesn’t *really* need to be done by the end of the iteration as long as it is mostly done. You might find that the developers who knuckled down and completed their stories only to find their buddy presenting their semi-complete stories may not be as focused for upcoming iterations.
• Devaluing QA – Going through the testing process is an integral part of delivering a fully-functioning application. Skipping straight past QA and presenting to the customer during the iteration meeting sends the message that QA isn’t a valuable part of delivery.
• Lower Quality –Reviewing untested functionality in front of stakeholders and the whole team can waste time and reflect badly on the whole team. You are much more likely to encounter serious bugs, stack trace errors, and other gaffes that can be quite embarrassing, and cause legitimate customer concern.
  

Reviewing incomplete stories with a customer outside of the iteration meeting for some course correction is a useful practice. Just don’t dilute a perfectly good iteration review with half-baked stories.