How to better understand estimations on complexity considering a comparison with time?

Scrum doesn't dictate a particular method of estimating work effort or complexity and relative sizing using story points (Fibonacci-based or other) is just one way of doing this. In fact, if teams get good enough at identifying work items (e.g. stories) then rather than size individual work items, you can size the backlog as a whole based on the total number of "small enough" work items.

Kiron

Dear Sérgio,

I truly appreciate your comment and I just added the Cone of Uncertainty to my library to explore asap.
I must agree with "story points is the "worst" method from the point of view of the high amount of uncertainty it has due to subjectivity."
I'm new to this team and this is the current setup/framework. We have proper refinement meetings where I feel the estimations are not being properly done - as well as uncertainty allows us - since we do not have a measure of comparison to the story points.

In my previous company, I worked remotely with 10 developers in India. Due to the constant hiring, we used our Refinements to use story points as well to estimate. After a few weeks/months we all together managed to compare that some things were not right because we were not estimating considering the time the feature would take to be develop but its complexity.
Is it possible somehow to connect both? Complexity + time?

With this previous team we managed to define that:
3 pt was equivalent to low complexity feature with no dependencies from other disciplines and easily managed during the sprint (the ant)
5 pt was equivalent to medium complexity feature with no dependencies from other disciplines and easily managed during the sprint
8 pt was equivalent to medium complexity feature with dependencies from other disciplines and managed during the sprint
13 pt was equivalent to high complexity feature with dependencies from other disciplines and with difficulty managed during the sprint (the whale)

Does this make sense to you?
Any advices?

Thanks in advance

Dear Keith,

As I said, I'm new to this team.
Complexity is considered the necessary effort in time and resources to deliver a certain feature during the Sprint :) I'm open to feedback in order to make this the best way possible

It is possible? Yes. It is recommendable to be successful? No. How I can understand the time it will take? Because the distribution of story points into sprints. That is the challenge. That is one of the biggest "shift of mind" when you use Agile with story points. That is the point where people with a real experience on the field take advantage. For example, because missunderstandings about estimations in general and story points estimation in particular there are movements like #NoEstimate (I have interacted a lot with them from the begining and I have demostrate them: change the name because what you are doing is estimating...)
About your points, let me say: there are a lot of ambiguity inside the criteria then in my personal opinion you still do not get low rate of uncertainty (uncertainty is risk as a component of estimations)
So, what to do?
Agile is based on knowledge. That is inside the definition of Agile when Agile was born (before software)
How to get knowledge? Some people that work with Agile say "taking it by prove and error, learning from error". That is not right but it could be a way
Using story points is one of the items (perhaps the only one) where you will assure the points given to features from knowledge and that is the reason because you need at least three sprints to get that. That is one of the points where "top management support" mean they accept the situation. That is one of the points to take into account when you decide to use agile because the company culture (and the whole architecture) has to be taken into account.
Take into account it: "a story is a placeholder to talk about". Think about all the implications when you have a user story on hand and you need estimate how much it takes to create something from it
I hope I have helped you. If not, please continue with your comments. It helps me a lot.

Ana,

I asked for a very specific reason. The term "complexity" is often misused as a technical term and confused with "complication" which are two completely different things. What complexity describes is the number of things interacting. By contrast, complication is a perceived level of difficulty. For example a "housing complex" includes a number of houses making it complex, however it might not be complicated at all. One very unique house can be very complicated however by itself it is not complex.

I say that because I find that the Fibonacci sequence often does scale well based on complexity, but not necessarily on level of difficulty or how complicated a problem is. Part of why is that the level of difficulty may be very subjective if not defined in precise terms.

While that might sound like me just trying to sound smart it is a very important distinction in this situation. You are trying to find a relation where:
x = f(y) (x is a function of y) where x = the time it takes to complete and y = the "complexity" of the problem

If you are using a subjective degree of difficulty, the Fibonacci function may not actually be meaningful from a statistical correlation so your estimating ability may be hampered by using the wrong function. You might be better served by better quantifying the level of difficulty or finding a different function to estimate time based on difficulty then the Fibonacci sequence.

This is where a coefficient of correlation is useful. If X does not correlate to Y, you either have the wrong function, or you may have variability in how you define Y.