Let's imagine you are in a Scrum team applying more or less correctly the methodology. You did your Sprint planning meeting, you heard about what it has to be done and discussed it the time for a planning poker estimation.
You see a ticket in your Jira, ready column, and you decide to "take it". How should you proceed ? I will first give you my suggestion tl;dr way and then I will try to justify why I think this way is very effective.
First of all, take some time to carefully read the ticket. If you have acceptance criteria attached, read them well. Make your own idea about what has to be done.
When you think you are done (it should take no more than 15 minutes if the task is reasonably dimensioned), you call your PO. YOU explain him what it has to be done with your own words. He listens carefully and then he gives you his feedbacks. Probably something you got slightly wrong, something you missed, something you added rightly and he didn't consider (you can decide together to modify the ticket). This meeting should also take around 10 minutes.
Once you are done, you open your IDE. You think about how you will concretely implement what has to be done. You look at the code you have to modify and try to imagine how you will do it. Which files are to be created/modified? Are there problems to solve? Are there possible side effects? Architecture best practices that apply?
This will probably take a little longer, but you should timebox it in 30 minutes max. If there are hard points, isolate them with precise questions. Once you are done, again, you call your lead developer/scrum master. You share your screen with the "code open" and YOU show him exactly how you intend to proceed. And ask the precise questions.
He listens to you and gives you his feedback: forgotten best practices, side impacts, ideas of better algorithms. He can answer the questions directly or take the responsibility to find an answer or you can decide together how to proceed to find a solution. This call can take up to 20 minutes.
That's all! I promise you that you will come out of this process with a very clear idea of what to do and a very good focus on the task to be executed. All the process will take less than 1h30'.
Why it works
First of all, your state of mind when you have to concretely start a task is very different from the one you have when you just make plans for it, even in short term. This makes all the difference.
Second of all, you take the charge to expose your point of view. You are using your terms and your technical vision, your interpretation. This avoids a lot of misunderstandings.
You take the time to prepare the calls and expose. These are excellent learning techniques.
There is no time waste for the PO and the lead dev. They can easely dig into the subject and been brought to the point. They don't have to investigate on their own side.
If YOU are the lead developer, for the technical refinement you call the most experienced engineer in the team.
You can be pairing (congratulations!). If you are pairing with the lead developer, no need for technical refinement. If you are junior and you are pairing with another junior, do the preparation work together and then call the lead developer.
I find a kind of a hole in the agile literature concerning the precious moment of starting a task. To pretend that everything is clear after the sprint planning is a lie. I have never seen this happen and I think there are good reasons for it.
Even with all the improvements agile techniques contributed to requirements specifications, there are common threats that affect user stories and acceptance scenari that land on a Jira ticket. Just to cite some, flawed humans that make mistakes and lack a perfect knowledge, imperfect organisation and reality time constraints that shorten or hinder 3A meetings.
And there is still the mental space of the person or the pair taking charge of the complex activity of realizing the implementation of the user story.
There is an extensive literature in human factors, ergonomic and activity theory studies on this. It is worthy to know at least a little bit of it.