This conversation reminds me of an electronic relay assembly line I once observed over a period of time. The workers hand-soldered relays, their numbers were being measured/judged, so many cold welds were shipped.

QA sent them to soldering classes, where temperatures and flowing of solder were discussed/practiced. They came back with nicely soldered joints, and production numbers dropped to the floor.

Management came back in, exhorting higher numbers, so out came the cold welds again to make the numbers.

It's your (shared) responsibility to determine what done is, and you should have a hand in estimating how long tasks will take. In my opinion, you as the engineer are ultimately the one who decides what quality you will accept. Instead of saying/thinking "it's done, but I'm not happy with the code quality yet", just say "it's not done yet".

I also firmly believe you should review all code before you commit it (would you skip proof-reading a paper before turning it in?), and that's an excellent time to spot easy improvements, places that need documentation, code that doesn't make sense, etc.

- Well it sounds silly but there will be fewer tickets when you slow down.

- If you work for a company where you're not free to question the legitimacy of tickets, get out now.

- Not all tickets should need to be done by the end of the sprint, but rather what can be done well or what legitimately NEEDs to be done for buisness reasons. I know your manager mught say everything needs to be done but that is a bold face lie.

- If you're throwing together garbage just to get the tickets done by the end of the sprint you are doing Agile wrong and just building technical debt rather than a product.