Issues with "Story Point" estimates in the era of agile transformation

Over the past years as companies and organisations take up agile transformation initiatives, the challenge of estimating work has taken multiple turns around "Story Points".

My understanding of the concept of story point is about a number that reflects the "size" of the work being estimated. This simple understanding become difficult to comprehend in collaborative work environments, where numbers mean different things to different Peoples/stakeholders.

The number may quantify "the complexity" of the work to be done, but that raises the question/issue of "what is complexity and how should it be measured/quantified". It may as well quantify the time required to complete the work, but that depends on the resources that will in the end do the work. On another note, it may quantify the volume of work to be done, but again, how should the volume of the work to be done be measured/quantified?

The above aspects add to the issues of correlating the size of work to the required resources to do the work as well as the cost of doing the work. These issues may be difficult to address in an agile transformation initiative. Especially when the perspectives and view points are constantly changing within and across stakeholders.

In my humble opinion, guiding rules and principles on how to derive and interpret "Story Points" within the agile transformation initiative/program must be communicated clearly to avoid irrelevant comparisons of quasi arbitrary numbers that mean different things to different people/stakeholders.