how to measure tech debt

Can you clearly sate what the question is? 

(question is how to normalize this)

How to normalize what? Please write it in active statement. Please add your thoughts separately after the question if you want. Right now you are mixing what you think the question is, what you think the question means, what you think the answer should be into one mix. This will make it hard for us to understand what your actual question is.

ok.. let me rephrase it

  How to measure  tech debt and its impact to any project delivery? its impact on any time to market and cost of change.

which method of the below should we use to derive it?

1. overall cost of a sprint divide by story points delivered to measure cost per change.  (question is how to normalize this)

2     take time when backlog was created vs when it was delivered to get Time to Market.  

How to measure  tech debt and its impact to any project delivery?

Let's go back a step. How would you first make technical debt transparent?

What is the specific problem that you are trying to solve?

Both of the measurements that you propose have problems, and neither would directly and specifically measure technical debt.

Measuring the time from creation of a Product Backlog Item to delivery is lead time. However, you do need to be careful about when you start measuring. For example, some teams that I've worked with will put a placeholder in the Product Backlog that is not suitable for working, but leads to conversations and more specific work. This placeholder will never be delivered, since it's too vague and broad. Measuring too early may not be valuable if the idea isn't solidified enough, but measuring too late would get you closer to cycle time rather than lead time. Depending on when you measure, you can learn about different parts of the product development life cycle.

Normalizing story points isn't a meaningful measurement. There's always some level of ambiguity and uncertainty in story points. The value of story points also change over time as the team's environment changes and they learn more about the domain, the tools used for delivery, the product or service being delivered, and improve their processes. As soon as you have multiple teams, it's also not possible to compare story points across teams. If a team opts to use story points, I do my best to ensure that nothing related to story points leaves the team since the measure is only useful within the context of a single team for a small period of time.

It's difficult, but possible, to quantify technical debt. My recommendation would be to analyze the product under development to find instances of technical debt. Performing risk analysis on the various pieces of work that can reduce technical debt can help to determine what the cost, in terms of money or time, would be.

I found this article that I believe will answer your question best (there a lot more on web). It explains why technical debt occurs and how to prevent this from happening and explains a logical way to measure it. I like this method as it directly exposes the cost impact of technical debt. Below is the excerpt from that article

Express technical debt computation as a ratio. A ratio of the cost to fix a software system [Remediation Cost] to the cost of developing it [Development Cost]. This ratio is called the Technical Debt Ratio [TDR]:

Technical Debt Ratio = (Remediation Cost / Development Cost) x 100%

Really simple isn’t it! Technical Debt Ratio [TDR] is simply the ratio of remediation cost to development cost.

And I agree with what Thomas Owens has explained above.

Normalizing story points isn't a meaningful measurement. There's always some level of ambiguity and uncertainty in story points