In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum.

At the end of the iteration, they have a unfinished tasks and one of two things happens.

The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to completing tasks within the scrum" (regardless of the fact the task will take as long as it takes, and same SM/PO/Manager has been ignoring the problems mentioned in the daily stand-up).

Or, they mark that task as "complete", but make a new story for the remaining testing/bug fix/additional requirements work. They eventually have to deal with the fact their burndown chart is almost flat, since they're creating a half point of work for every point they close.

They also have people who complete their tasks early, but don't want to bring in another story, because that's "a violation of Scrum". Or they're worried about not being able to complete it by the end of the iteration and going through the previously-mentioned problem.

And no amount of bringing this up in retrospectives will change anything. In the scientific method, if your hypothesis fails in reality, you reject the hypothesis and search for another. In IT project management, when your process fails in reality, most people apparently prefer to reject reality.

Just admit you're doing Kanban and stop causing the problems created by arbitrary deadlines created by your iterations.