Straight from the SAFe frame work.. In SAFe here is the thought process behind Normalizing points
Relative Estimating, Velocity, and Normalizing Story Point Estimating
Agile Teams use relative estimating [2, 3] to estimate the size of a story in story points. With relative estimating, the size for each story is estimated relative to the size of other stories. The team’s velocity for an iteration is equal to the sum of the size of all the stories completed in the iteration. Knowing a team’s velocity assists with planning and is a key factor in limiting WIP, as teams simply don’t take on more stories than their prior velocity would allow. Velocity is also used to estimate how long it takes to deliver larger Features (/features-and-capabilities/) or Epics (/epic/), which are likewise estimated in story points.
Normalizing Story Point Estimating
In standard Scrum, each team’s story point estimating—and the resultant velocity—is a local and independent matter. The fact that a small team might estimate in such a way that they have a velocity of 50, while a larger team estimates so as to have a velocity of 12, is of no concern to anyone. In SAFe, however, story point velocity must be normalized to a point, so that estimates for features or epics that require the support of many teams are based on rational economics. After all, there is no way to determine the return on potential investment if you don’t know what the investment is. In order to do this, SAFe teams start down a path where a story point for one team means about the same as a story point for another. In this way, with adjustments for economics of location (the U.S., Europe, India, China, etc.), work can be
estimated and prioritized based on economics by converting story points to cost. This is particularly helpful in initial PI planning, as many teams will be new to Agile and will need a way to estimate the scope of work in their PI. One starting algorithm is as follows:
For every individual contributor on the team, excluding the Product Owner, give the team eight points (adjust for part timers).
Subtract one point for every team member vacation day and holiday.
Find a small story that would take about a half-day to develop and a half-day to test and validate. Call it a 1.
Estimate every other story relative to that one.
Example: Assuming a 6-person team composed of 3 developers, 2 testers, and 1 PO, with no vacations, etc., then the estimated initial velocity = 5 * 8 points = 40 points per iteration. (Note: The team may need to adjust a bit lower if one of the developers and testers is also the Scrum Master.)
In this way, all teams estimate the size of work in a common fashion, so management can thereby fairly quickly estimate the cost for a story point for teams in a specic region. They then have a meaningful way to establish the aggregate cost estimate for an upcoming feature or epic.
Note: There is no need to recalibrate team estimating or velocities after that point. It is just a common starting point.
While teams will tend to increase their velocity over time—and that is a good thing—in fact, the number tends to remain fairly stable, and a team’s velocity is far more affected by changing team size, makeup, and technical context than by productivity changes. And, if necessary, financial planners can adjust the cost per story point a bit. This is a minor concern
compared to the wildly differing velocities that teams of comparable size may have in the non-normalized case.
Link for Reference http://www.scaledagileframework.com/iteration-planning/