Day one of the sprint and my coworker has already found some fucked up requirements.

Goddamn do I hate this shit sometimes.

Good it is not day 10

In these situations I find it helpful to ask if the team has defined a strict policy that tickets should be properly defined before they are placed in a sprint.

I have been in a team where all us devs were under the impression that this was the case, but stakeholders thought that requirements in a ticket were just some "initial ideas" that would "probably have to be revisited/revised/rewritten whenever a sprints starts and someone actually starts looking into the ticket in detail"

After this we had a discussion and started using 2 different labels for tickets: a) well-defined b) fuzzy

Follow up: sometimes I prefer tickets with 'fuzzy' requirements.

If a ticket is the top priority and "should be worked on until it's done" I'm fine with it being poorly defined and the team can just say "Let's just have a dev, a designer start working on this and talk to a stakeholder to define where it needs to go"

Because I dislike all the meta-work around backlog refinements, pre-planning tickets, all the guesstimates. I love just "work on this until it's done"