Let me ask you a question. How long will it take to run a marathon? 2 hours? 4 hours? Ahh. it depends. It depends on who is running the marathon. An experienced runner will probably finish sooner than an inexperienced runner. It probably also depends on the terrain. A flat terrain will be easier than a steep terrain. So a lot of factors will have an impact on the time to run a marathon. But if I would ask you "How long is a marathon?" you would know the answer, and it's the same for everybody.

The same rules apply to a problem. You cannot know how long it will take to solve a problem. In software development a senior developer will probably solve the issue much quicker than a junior developer. If you know the code base and have been working on the project for a year - even if you are a junior - you probably fix it quicker than the senior developer who just started last week.

But what metric do you take to assess a problem? How about 'complexity'. Every problem has a level of complexity. But since we do not have an international scale for complexity, like meters or inches, we need to define our own scale. You can do this by creating a reference problem. A problem everyone in your team understands, like changing a flat tire if you work in a garage, and give it a complexity of 1. Based on this reference, everybody will be able to measure any problem's complexity based on that reference problem. If you want to have more accurate estimates, you can create multiple reference problems for your team.