We're experimenting with following an agile approach to software development where I work. It's working well so far, however, towards the end of the iteration, we had a problem with a build and it cost a day's worth of time fixing: time that should have been dedicated to testing.
As a result, our QA doesn't have enough time to complete the testing before the end of the iteration. How do you deal with this scenario - where unforeseen problems impact on tasks during the iteration?
If you cannot test the iteration output in the agreeed manner, we normally take zero points for the sprint (or whatever points can be tested). It feels tough right there & then but it has turned out to be a sensible thing to do.
(The last sprint of a project is obviously differemt)
By having an single handoff between your development and QA you've created a single point of failure in your iteration. You already let this iteration slip a day by not delivering to QA in time. Making up time by rushing QA isn't the answer.
You could improve this situation by delivering to QA more often, ideally you'd do this every time a feature is done. If the last build fails QA can just test the previous build and you'll have to move the feature that was implemented since then to the next iteration.
Agile canon is that you only count those stories/backlog items as done which are DONE - and typically your definition of DONE should include "being tested". So, you simply don't get credit for the stories that aren't tested yet. After all, a similar problem might arise next iteration, too.
It's not totally clear from you question on how QA is integrated in your process. In general, you should make sure that bugs can't escape a sprint, because otherwise your velocity becomes very unreliable.