why product backlog refinement is not a scrum event

That is correct, refinement is not a formal Scrum event because it doesn't have to happen. It is a good practice, but not always needed.  Ken and Jeff have had this discussion quite often and in this discussion, it always comes back to "Does every Team have to do refinement in every Sprint".  The answer is no and therefore it is not a formal event in Scrum.  It is however a recommended good practice for teams to use as needed.

Is product backlog refinement not part of scrum event?

Refinement is contained within the Sprint event, but is not a Scrum event itself.

interested to know what possible reason behind it.

Refinement is an event when Scrum is implemented in a Nexus. Can you see why?

Refinement is an activity that can be accomplished in many ways.  If someone reads something and asks a question, is that not refinement? Events are things that happen on a recurring basis and usually involves a group of individuals coming together at a specific time for a specific purpose.  Activities are things that occur at any time at any place when individual(s) chooses to make it happen. 

Some of the best refined Product Backlog Items my teams have worked on were never discussed in a conference room with people. They were refined via conversation at desks or via comments left in the system used to track the items. The Scrum Guide mentions refinement in one place.  The section where the Product Backlog is discussed.  And it states that the team should spend approximately 10% of their time doing it.  Because it is an activity, the individuals participating can determine how best to do so.  If they want a weekly meeting they can schedule it.  But that is their decision. 

Although the other answers are great, I'd add two things.

In Scrum, even though it's not an event, the team's I've worked with have tended to have success getting together outside of Sprint Planning briefly to review the refinement work of other teams and either ask more questions that the person or small group performing the refinement may have missed or to make sure that the entire team's estimate is accounted for. The adding of detail tends to be an individual or small group activity that happens throughout the Sprint.

When scaling to multiple Scrum teams, both Nexus and LeSS elevate Product Backlog Refinement to an event. Nexus does not define how often or who attends the Refinement, but acknowledges that it's a series of decomposition steps from large and vague requests all the way to work that a single Scrum Team could deliver in a Sprint. LeSS has an initial Overall Product Backlog Refinement which is short and addresses high level questions and allocates Product Backlog Items to Scrum Teams and both single-team and multi-team Product Backlog Refinement sessions that turn the work into something that is actionable. With multiple teams working on the same Product Backlog supporting the same product, elevating to an event of its own can help make sure that knowledge of the refinement is shared across all of the teams to make sure that dependencies are identified and there is knowledge of the work being undertaken across the teams.

In addition to what everyone else mentioned, I'd add that the Scrum events are time-boxed (i.e. the Daily takes at most 15 mins), whereas Backlog Refinement, if needed, is ongoing and optional. And not everyone on the Scrum Team needs to be there.

Refinement is an event when Scrum is implemented in a Nexus. Can you see why?

@Ian Mitchell, is it because it helps eliminate/reduce dependencies between teams? If not could you help with the answer please?

What other reasons could make it an Event in Nexus vs regular Scrum?

 

Is it also because of the fact that in a scaled environment it helps collaboration? Would it be necessary for everyone to be present in a big room like in SAFe?

Resolution of dependencies is indeed the principal reason. The overhead of managing refinement as a formal event is likely to be justifiable if 3 or more teams are involved.

The matter of attendance is best left to the teams and their appreciation of risk. The Nexus Guide says “The number, frequency, duration and attendance of Refinement is based on the dependencies and uncertainty inherent in the Product Backlog.”

That is correct, refinement is not a formal Scrum event because it doesn't have to happen. It is a good practice, but not always needed.  Ken and Jeff have had this discussion quite often and in this discussion, it always comes back to "Does every Team have to do refinement in every Sprint".  The answer is no and therefore it is not a formal event in Scrum.  It is however a recommended good practice for teams to use as needed.

@Eric Naiburg, I'd like to challenge that thought only because I don't see it in the guide and also for my own clarification and learning.

The guide mentions that it is an ongoing activity, but it does not explicitly say that it is optional. Wouldn't ongoing therefore imply that it happens, but how, when, and the frequency is upto the Scrum Team to decide? Also, if the Scrum Team is only doing "just enough" forward planning, wouldn't refinement somehow always be a part of the Sprint? Though I can see how common sense may dictate why it may not be necessary always.

It would perhaps be more helpful if the language said something like "refinement is an ongoing activity, however it is optional and is done as needed." Thoughts?

IMHO, backlog refinement is not included among Scrum events simply because it does not exhibit all the same characteristics of a Scrum event: The 4 Scrum events are time-boxed AND begin and end at a specified point on the Scrum timeline AND are necessarily only related to the current Sprint.

Backlog refinement is time-boxed, but, conversely, it's execution is not mandated to begin and end at a specific point on the Scrum timeline. Any item, regardless of its relationship to the current Sprint, may be the subject of refinement at any time (while high-priority PB items will naturally receive the majority of attention). This may include a poorly decomposed/estimated/understood item that the team pulled into a Sprint, failed to complete, and is therefore returned to the Product Backlog for remedial refinement and (re)prioritization.

I strongly disagree with the answer that states "refinement is not a formal Scrum event because it doesn't have to happen". I think this perspective misses a huge point:

Refinement's execution or lack thereof is not predicated on whether it's an event or not.

Instead: Estimates are needed by the work team at Sprint Planning so they can determine what they'll elect to pull into the Sprint, e.g., they'll pull N story points worth of stories where N equals their historic velocity (plus a smidge). Estimates are created during refinement So, refinement can be skipped only if there are always enough refined items in the PB to meet what the anticipated "pull demand" will be at the next Sprint Planning meeting. Otherwise, the pipline will run dry. In practice, to be safe, I would strive to maintain enough refined stories in the PB to satisfy the sum of the velocity of all teams that will be pulling stories at the next Sprint Planning meeting plus, say, 20%. If the PB meets this criteria, then you can "skip" refinement (for a while)

That is correct, refinement is not a formal Scrum event because it doesn't have to happen. It is a good practice, but not always needed.

For me this statement resonated because of the term 'formal Scrum event'. To me that does not imply it never happens.

"Does every Team have to do refinement in every Sprint". 

What if we had enough "ready' Product Backlog in place for the next Sprint, should the Scrum Team still hold a formal meeting?

Scrum Guide: 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.

Remember Scrum is intentionally incomplete, and not a formal prescriptive methodology. To me the Scrum Guide says that PBIs need to be refined, just not in a formal meeting that is time-boxed. To me this fosters a form of self-organization where the teams can decide how and when.