The most important work?

We've been assigned a ticket.
We look at the ticket.
Hmm, vague requirements.
Now we have a choice, a decision to make.
Do we ask for the requirements or do we try to figure out what the requirements are likely to be by making some educated guesses?

Let's explore the second approach first.
The difficulty level of tickets ranges from very simple to very complex.
Sometimes they are so simple, making educated guesses is absolutely the right way to go. Sometimes they are so complex, making educated guesses is not advised and can even be impossible.
It's usually somewhere in between.
We can ask ourselves, "Is there an industry standard for this type of thing?" or "Have we already done something similar?".
Sometimes you find an answer right away that fits perfectly.
Sometimes you find something similar that is probably a good model for solving the problem.
Sometimes you search and search and find nothing and end up having to ask anyway.

Now let's dive into asking for the requirements.
The first thing we need to do is figure out who to ask.
We can't expect a good answer if we're not asking the right person.
It's not always the creator of the ticket but that's usually a good place to start. If the creator of the ticket isn't the right person, they might be able to direct us to them.

Trying to figure out the requirements can be much faster and much easier if the requirements are easy to guess. When they're difficult to guess, it can be much slower and much more difficult.
And we might guess wrong.
We might guess wrong and we'll have to redo all of the work.
We might guess wrong and nobody catches it in code review or QA and it makes it out to production.

Does asking for requirements look like the better approach?
Well, what if the person we ask doesn't know?
What if they can't direct us to anyone who does know?
The person we're asking needs to be able to answer our questions.

From my experience, the main reason for vague requirements is that they haven't been worked out yet.They never got past the "That's a good idea. Let's do it." stage. We can ask for requirements but they can't give us what doesn't exist.
They will need to be worked out.

So, which approach is better?
To better understand this we need to know why the requirements are vague in the first place. If it's because the task is simple and self-explanatory, making an educated guess is probably the better plan. If they are known but not included in the ticket due to an oversight, asking is the better approach.
We can avoid both if we're dedicated to producing clear, concise requirements up front.

Figuring out the requirements of a task is hard work.
It's hard but it's the work that keeps things moving.
It's the work that prevents problems.
It's the work that keeps people sane.
It's the most important work.