Questions about product backlog refinement and other topics.

I believe all three statements are correct in practice, but I would take any numbers as guidelines, not rules. The time needed can vary depending on the complexity of the sprint. Some sprints may require more time. A product has one backlog, and while teams may generally focus on their own tickets in the PB, there will be situations where they need to collaborate to resolve dependencies.

In the Scrum Guide, sprint planning is timeboxed to a maximum of eight hours for a one-month sprint. Eight hours of planning for a three-week sprint is, in my opinion, quite on the long side. In my experience, teams roughly plan for an hour per week in a sprint. Teams new to Agile have not always mastered having focused and concise conversations in meetings, and meetings can run way over time.

That being said, I do not recommend getting too focused on specific hours; use the time necessary as the particular project demands.

Question ... are you trying to pass the exam, or are you after real-world experience?

My answer to a) would be 1, the Scrum Team can refine at any time.  My team meets once per week where we discuss "homework" that was assigned the week before.  A level of design is discussed & agreed between all Developers & the PO, PBIs are Story Pointed, & we assign homework for the next week.  Each Developer completes their homework when they see fit & Sprint commitments are made with that in mind.  Perhaps not the most traditional way of doing it, but it works well for us.

For b), the Scrum Guide says "Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint.  For shorter Sprints, the event is usually shorter.", usually being the operative word.  There is no hard & fast rule, no ratio to maintain.

I have some questions regarding Product Backlog refinement and would appreciate your insights. 

Where did you get these questions from? Scrum is minimally prescriptive, and they seem to assume hard and fast answers.

a. Specifically, which of the following statements are applicable to Product Backlog refinement?

1. It can happen anytime during Sprints.
2. It doesn't take more than 10% of the Product Owner's time.
3. Multiple teams can participate.

Scrum doesn't have a lot of definition around how teams perform Product Backlog refinement activities. The word "refinement" only appears once in the Scrum Guide, and "refine" only appears twice in the body. However, we know that "the Product Backlog is refined as needed" and that refinement "is an ongoing activity", including some refinement activities occurring during Sprint Planning.

Statement 1 - refinement can happen any time during Sprints - is generally true. However, in my experience, it isn't an ad-hoc event. Teams typically define how they go about refinement, and I've seen many variations in how teams refine the Product Backlog. Reviewing the effectiveness of refinement and how it is setting the team up for success in upcoming Sprints can be assessed at the Sprint Retrospective.

Although the Scrum Guide defines how a Scrum Team works, scaling frameworks like Nexus and LeSS take the core concepts of Scrum and apply them to multiple teams working together to develop a single product. There are several approaches about if and how to include multiple teams in refinement activities. I would claim that statement 3 - multiple teams can participate - is also true, especially given the use of "can" over a stronger word like "shall" or "must".

The only statement that I would disagree with is statement 2 - refinement should not take more than 10% of the Product Owner's time. This statement appears to be based on old revisions of the Scrum Guide, where there was a suggestion that the team allocate about 10% of their capacity each Sprint for refinement. Although I consider this a good heuristic, it's not a hard rule. It also talks about the team as a whole, not the Product Owner. Depending on exactly what you consider refinement (as opposed to, for example, "creating and communicating Product Backlog items" or "ensuring that the Product Backlog is transparent, visible and understood"), it very well could be far more than 10% of their time.

b. If a team of 8 people is working in three-week Sprints and has timeboxed their Sprint Planning meeting to 8 hours, does this mean that shorter Sprints should have a correspondingly shorter timeframe for Sprint Planning?

What are the recommended practices for Sprint Planning duration relative to Sprint length?

The Scrum framework defines maximum timeboxes for the events. Sprint Planning is, at most, an 8-hour event. However, like most events, the Scrum Guide does say that if the Sprint is shorter, "the event is usually shorter".

In my experience, the relationship is usually proportional. That is, since the 8 hour timebox is designed for a 1-month Sprint, a heuristic would be to plan on about 2 hours per week in a Sprint. Allocating 2 hours for a 1-week Sprint or 4 hours for a 2-week Sprint is a good starting point.

There are some caveats, though. For example, a team that is new to agile ways of working or the Scrum framework is often learning how to effectively execute the events. Embedding the learning into the event often makes the event longer. For Sprint Planning, specifically, the team's refinement practices have a direct impact on how much time needs to be allocated to planning. I've also observed that specific events, like changes to the Product Goal as a result of a Sprint Review could invalidate the state of the Product Backlog and require more investment in planning the team's next steps.

There's also the consideration of how much time to block on people's schedule. The event should always be completed within 8 hours. But if your Sprints are shorter and the event is usually shorter, it may not necessarily be wise to schedule the exact length on people's calendars. It may be easier to pad the length to account for the unexpected. Perhaps allocating 4.5 or 5 hours for a 2-week Sprint would account for the unknown that may arise, such as needing to do a little more refinement within Sprint Planning.

a. Specifically, which of the following statements are applicable to Product Backlog refinement?

1. It can happen anytime during Sprints.
2. It doesn't take more than 10% of the Product Owner's time.
3. Multiple teams can participate.

In my opinion the only one that is completely applicable is #1.  I actually encourage the teams for which I am involved to continuously refine the Product Backlog. If a Developer needs to take a break from the code they are writing, they can spend some time looking through the Product Backlog to see what is there.  Almost everyone uses some form of electronic system to maintain their backlog, so I encourage that the comment section be used for asynchronous refinement.  There have been many items in our backlog that never had a face-to-face discussion because the comments section provided the entire refinement process.  #3 could be applicable if the team felt that it could be useful.  I've had some items that where the team wanted some outside opinions because other teams had done something similar. 

b. If a team of 8 people is working in three-week Sprints and has timeboxed their Sprint Planning meeting to 8 hours, does this mean that shorter Sprints should have a correspondingly shorter timeframe for Sprint Planning?

Not necessarily.  As others have said, it depends on the team and the work that is being planned. However, if it takes more than 8 hours to plan a 4 week Sprint, then I would question how well the Product Backlog refinement has been done. With some of the teams I have worked, they have planned 2 week Sprints in about 5 minutes because they have done such a good job of refining the items, they all had a fairly clear idea of the work that would be needed. 

I do coach that Sprint Planning is not a time where detailed tasks are written up and each assigned to specific individuals so that a project plan is created.  Since the Developers have an event every day where the purpose is to share information and plan the day's activities (Daily Scrum), there isn't a need for such detail to be developed. 

Thank you so much for all your responses.
@ Damien Reed, @ Ian Mitchell- Yes, I'm preparing for the PSM1 exam. I had a question regarding Product Backlog refinement. Specifically, is there a set percentage of time that should be allocated to it? I didn't see this mentioned in the current Scrum Guide, but I came across some older information online suggesting a specific percentage. I wanted to confirm this before the exam.