What do you think about Backlog Refinements (formerly Backlog Grooming)
The Scrum Guide says that refinement is an “ongoing process”, but what does that mean in practice?
We have complex projects in our product, and we adopted as a practice to sit 2 hours mid-sprint, and groom the backlog. The main reason why we do this, is because many of the topics are very complex, they often require clarifications from the business, so we try to antecipate the questions so we have the answers (so we can estimate the US) once we get to the Sprint Planning meeting.
Is this a good practice?
The Scrum Guide says that refinement is an “ongoing process”, but what does that mean in practice?
It means that work is continually being made Ready for Sprint Planning. The Developers then know the work can be Done in a Sprint, and they will just need to plan whether they ought to do it or not in order to meet a good Sprint Goal. There will be no nasty surprises.
If you have a fixed time where the team performs refinement, that doesn't strike me as an ongoing practice.
Although getting the whole team together, perhaps on a regular and scheduled basis, is important, I've found that the best and most effective refinement happens outside of these meetings with the whole team. The meetings are important for a few reasons: the Product Owner can introduce the most recent state of the Product Backlog, the team can see what is refined and ready and what is not, the team can update each other on what has been learned since the last meeting, and the team can decide on next steps to get enough of the Product Backlog to a ready state. The actual refinement - thinking through the problem and potential solutions, high-level designs and assessing impact, decomposing the work into smaller Product Backlog Items - happens individually, in pairs, or in small groups outside of the whole team meeting.
In your description of the refinement meeting, two things stand out to me.
First, how closely is the Product Owner working with and available to the team during the course of the Sprint? Saying that you need to anticipate questions to ask at the meeting seems to indicate that the Product Owner has limited availability to the team outside of this meeting. The Product Owner does have a lot of work to communicate with various stakeholders, but they are also fully dedicated to the team and should be working closely with the Developers (and the Scrum Master) every single day. There shouldn't need to be waiting for the refinement meeting to have questions answered.
Second, it seems like you are waiting for the Sprint Planning to estimate. For teams that do estimate, estimation should be part of refinement. If you aren't estimating, how do you know if you have sufficiently decomposed the work or if you should try to find ways to slice it into smaller, more deliverable pieces? Scrum has one rule for a Product Backlog Item being ready for a Sprint, and that rule is that the team can complete the Product Backlog Item within one Sprint. Some teams may enhance this rule and require a Product Backlog Item be something that can get to Done in a few days or less. If you're waiting for the Sprint Planning session to talk about this, then you don't know if it's refined enough and may end up taking on poorly refined work into the Sprint.
I agree with all of the above. Discussion is only a part of the practice of refinement. If the developers are not allowed time to think about the items on their own, how do they prepare questions?
...so we try to antecipate the questions so we have the answers...
That statement indicates that the Developers are thinking through the problem and discussing them outside of your meeting. In essence they are refining on an "on going basis".
Many organizations will include a scheduled gathering to be used as a Refinement Meeting. There is nothing wrong with this practice in my opinion IF, and that is a big IF, the individual developers take time on their own to review, think about, investigate the items that exist in the Product Backlog. In my opinion, if the only time a Product Backlog Item is considered is during that designated time, you are failing in your refinement efforts.