The activity in Scrum that causes most confusion is the backlog refinement. The scrum guide does not treat refinement as an event, like sprint planning or the retrospective. So it does not have a clear timeslot in the sprint. The scrum guide treats it as an activity that needs to take place, but leaves it up to you how to perform this.
The literal text about backlog refinement in scrum is:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
So, the goal of backlog refinement is that product owner and team work together towards a good product backlog.
In the picture below I give a sketch showing the timeline of a new idea to working software, which may help to clarify the refinement process.
A new idea starts with a stakeholder. This can be a customer with an idea or complaint, or someone from “the business” with a smart idea, or a developer with a technical suggestion. These ideas should be given to the product owner.
The meeting where this idea is discussed with the PO is the very first backlog refinement. Maybe it is just two persons talking with each other, but the idea gets refined a bit already. If the PO likes the idea, it is placed on the product backlog. You could call this part of the process the “business refinement”.
Next, the idea should be discussed with the development team. They should get a clear picture about the item that needs to be developed. They should also estimate how much work it is, so the PO can take an informed decision about whether or not to develop this. Do the expected benefits outweigh the expected costs?
You could do this refinement session with the whole development team, but you can also start with subset of the team. In this way you can develop this idea into something better without spending the time of a lot of people. You can also invite stakeholders to this meeting if that will lead to a better clarification. You could call this meeting a pre-refinement, or prefinement, if you want.
If the idea is clear enough, you can have a refinement session with the whole team, so everybody will share the same picture. This is the “real refinement” session, where you will also do the estimation. If necessary, multiple refinement sessions can to be conducted until the idea is really clear.
After refinement, items can be picked up by a team in a sprint planning session. If the refinement has been done properly, the first part of sprint planning is easy. Just pick up the right amount of backlog items where the sum of the estimates matches your planned velocity. After this, sprint planning II remains, where you do detailed design on the selected items and add technical tasks.
It could happen that there still is a need for additional clarification during sprint execution. If this is just about minor details, that is perfectly OK. You could call this the after-refinement.
Hopefully this clarifies the refinement activity a bit. Any questions or comments? Please let me know.