Final Sprint and Testing

This isn't a case of not defining done

So you are saying that you have an adequate definition of done? If that is true, than it is a case of not following the definition of done. However, I would recommend to also question the existing definition of done and look for ways to improve it.
"Stabilization sprints" are a clear smell which show you that agile practices are not being performed in the team.
You need to do a root cause analysis in order to identify where in the process the bugs emerge and how they can be found as soon as possible, latest before sprint end.
This kind of analysis is usually done in the retrospective.
The advantage is that you can give a better forecast to the customer, when a feature will be finished, and it can be in any sprint, not only after five sprints.

> The final sprint doesn't have new user stories in it but we can't do a release because of these bugs.

Each sprint increment must be potentially releasable. If you can't do that because of bugs then your implementation of Scrum is broken. As Ludwig says you really need to critique your Definition of Done, since this effectively asserts the quality of your sprint deliverables.

The approach you have taken is sometimes referred to as a pre-release "hardening sprint". Up until that sprint technical debt is allowed to accumulate along with waste such as defects. Although very common in industry, in agile terms it is an anti-pattern.

Thanks for the great responses.

I agree that the definition of "Done" needs to be critiqued especially with regards to building up the user stories for defining the work. That would be the number one problem. Each sprint done has been "potentially" releaseable (based on an internal definition of done) except when the final client was involved, as opposed to the Product owner who acted as the "voice" of the client.

But let me correct my earlier statement - It's not that we COULDN'T do a release; it's that the politics involved would not let a release go without certain items.

But your responses have been very helpful on this. This is an organization where change is difficult to achieve so being able to bring this type of response into the retrospective will be very helpful. It is helpful to identify to the organization that the assigned product owner was not able to act as a good representative of the client and this leads to the inherent problems in the delivery.

Thanks