The Scrum Guide was never very prescriptive about how to perform refinement. The November 2020 update removed one of the few pieces of advice that existed, which is that teams spend about 10% of each Sprint performing refinement activities. This guidance was deemed to be too prescriptive as teams were treating this as a rule and forcing themselves to this amount of refinement unnecessarily.
Refinement is typically done in advance of the Sprint Planning in which the work will be done, but very important Product Backlog Items may have been introduced at the most recent previous Sprint Review and the team may opt to attempt to sufficiently refine these items between the Sprint Review and Sprint Planning or at the Sprint Planning session.
My personal rule-of-thumb is that a team should have about 2 Sprints worth of work refined to the point of being ready for selection in a Sprint. How the team determines this varies based on how the team determines how much work to bring into a Sprint. If the team is estimating in hours, then about 56 hours per week of the Sprint. If the team is estimating in points and tracking velocity, 2 times the team's most recent Sprint velocity. This tends to balance between ensuring that there's a reasonable forecast of upcoming work to give stakeholders insight into what is coming next with not introducing planning and estimation waste. However, if there are extreme amounts of uncertainty, the team should consider refining less. If the organization is operating in a more certain and stable setting, it may be possible to refine more work, but I wouldn't go more than 3 or 4 Sprints worth of work.
How the team tactically executes refinement varies by team. I've seen a few different methods that have worked well.
One team that I worked with performed all refinement as a whole team, including the Product Owner. They would meet for a couple (~2 hours) each week and look at the top of the backlog, focusing on items not yet considered ready. They would be able to talk about the work, look through the code and identify any tech debt or pre-existing defects that could impede the work, identify dependencies or possible dependencies, decompose the work into units that can go through the whole life cycle, and estimate the work.
Another team only met briefly (less than 1 hour) every week or two. This meeting would identify what Product Backlog Items needed to be refined and people would take them on, as individuals or small groups. They would talk to the Product Owner and perhaps other stakeholders, get their questions answered, and begin to decompose the work into ways that made sense. At the meeting, the team would also review each other's work, make sure that everyone on the team had a shared understanding, there were no key unresolved questions that prevented the Product Backlog Item from being ready, and estimated the work. The amount of time varied per person and per Product Backlog Item.
Regardless of the specific tactical approaches, it's essential that the team should set aside time every Sprint to refine future work. No Sprint should be full to the maximum possible capacity of the team. My rule-of-thumb is that in a 40-hour workweek, 28 hours is the maximum productive work time. The other 12 hours account for overhead, waste, and slack. An organization should reduce overhead and waste, perhaps allowing productive work time to increase. However, there should always be slack. Slack not only gives time for refinement but also accounts for personal things that interrupt working hours or skills development or team building or something else entirely. Slack also supports things like enhancing the quality of the product.
