A few years back when I did my first project in Agile, we faced numerous challenges. But one of the main issues was estimating in terms of a story point. All of us came from traditional estimation techniques used for a waterfall or iterative model. So, estimation of a story and consider the complexity of the story was quite difficult for the team to apprehend and understand. After giving some thought to mitigate the issue (may be partial), I thought of an alternative method to get the final story point. I took some input for the concept from some article on the internet (don't remember the source) and then added more dynamics to it to arrive at the intended procedure. An overview of the table to get the story point is mentioned below.
I calculated the complexity using the formula "Complexity = Complexity Map * Testing Complexity."
The final story point is calculated as "Story Pointing = Story Sizing * Complexity."
If we see, there is story sizing value which is nothing but the value derived based some pre-defined criteria. Then we multiply the complexity with that to get the final value.
There is another table which actually drives the size and complexity values. The left section mentions about the size and right section depicts the complexity factors. The right section is divided into 2 areas. The first one is the simple complexity map which is derived based on certain defined criteria, the second one is the testing complexity (categorized as high, medium, and low). Ultimately we get the final story point by multiplying all these values.
The problem with this technique is that sometimes story with story size 8 can go around ~30 SP (mostly an EPIC) after considering the complexity. So, in this case, it is better trying to break that story into smaller stories and then consider those for implementation.