Story Points to user stories to scrum team correlation

There's no reason for any of these things to align at all, as long as the Developers in each team can make a reasonable forecast of how much work they can take on each Sprint, and produce at least one Done increment of work by the end of it. A Scrum team of 20 would perhaps find it difficult to collaborate on these matters, and could be expected to face significant difficulties.

+1 to @Ian's answer. 

Since you are just starting to learn about "Agile" it might be good for you to understand that "Agile" is used a lot talk about processes, tools, consulting, and other things that can be commercialized.  The term was created not long after the Manifesto for agile software development was created.  The manifesto itself was created to help organizations see how certain practices were more useful than others to enable agility or the ability to quickly adapt to change. 

Story points and user stories were established as part of eXtreme Programming (XP) which is not directly connected to Scrum but can be used complimentary in the Scrum framework.  This post by Ron Jeffries can give you a background in the creation of Story Points.  The Scrum Guide does not mention User Stories or Points anywhere. They are something that many organizations have chosen to use but are not expected as part of Scrum.  This is a blog post from 2017 here on scrum.org that does a good job of explaining that User Stories can be useful but they can also be unnecessary.  You can search "user stories" on this site and find a LARGE amount of information and discussion about them. 

In my understanding, a Scrum team of 20 will have a different story points count than a team of 10, or can they be the same?

This all depends on what you mean by "story points count" and how you intend to use it.  Story Points are specific to a story and are created at a specific point in time based upon the information known at that time. It is a relative estimate for that story.  The relativity is to other work that has been undertaken by that same team.  There is no "standard" model for story points and they are only useful as a planning tool for the team that made the estimate.  Trying to compare teams based upon story points is like trying to compare sport teams based upon how many points the players think they will score in each game based upon what they know about the team they will be playing. 

We might be able to help you better understand this if you gave us a more specific question.  The question you asked is very vague and it indicates that you are not very familiar with agile practices, as you indicated.  So, I'm going to introduce you to the practice of refinement. You have provided a very high level description of a problem that needs to be solved.  Now, start breaking it down into smaller, more actionable chunks. 

• Do you fully understand Scrum?
• Do you fully understand User Stories? 
• What is a Scrum Team?
• What would a Scrum Team use User Stories for? 
• What are Story Points?
• ...

This will help you to build up the information you need to start formulating your own understanding. You will incrementally begin to understand the concepts so that you can create the answer that you seek.  As you increase your knowledge you will most likely find new questions.  You may also learn new information that changes what you thought you knew about a previous topic. Keep going with this practice until you can no longer see any value in the information you seek and know.

BTW, I just taught you the basic building block of Scrum Product Backlog management and a core element of every agile practice you will ever encounter. 

To make long story short(relatively short), story points are not metrics.

They don't correspond with any physical matter: size, volume, charge, data count, space or time.

They are relative, and not exact.

Story points are internal estimates of Scrum team. Team makes them for itself when developers are forecasting upcoming work.

To help understand story points I usually employ following exercise.. Lets use my favorite model of Scrum team who is selling bracelets and earrings at the local artisan market ;) 

First step is asking the team to estimate the task difficulty: which is a combination of time and effort. In the beginning developers do it using T shirt sizes method...

Like S - small task, M-medium task, L-large task, XL is extra large task.

For example: printing the necklace using 3 d printer or stamping it by a press is a Medium task or M, and hand carving it would be Extra Large task or XL

Bringing the items to the market to the market by car is a large task or L, and putting the items on the stall is Small task, or S

So during the Sprint the backlog of this team would contain few M tasks, one XL task.

Using this estimates developers can then plan and inspect their own work during the sprint. Its a internal business of the team. And that is only use this estimates(not metrics) have...

So where is the story points place in that? Only reason why story points came out, and are numerical is because many teams like to use burn down charts, to validate own assumptions and having numerical values at the vertical graph is handy.

If team wants to use cumulative flow diagram or burn down chart to see how the production and sale of above mentioned necklaces and earrings go, they might "convert" the "t shirt sizes" into numbers using Fibonacci scheme (like XXS and XS task would be 1, S will be 2, medium 3, ML would be 5, L would be 8, XL 13, and so on, breaking it on 20)

Or assigning simply one-two-three numbers, if Scrum tradition of using Fibonacci sequence is to complicated for a team. Its up to the team to decide.

That's it. You have PBI(product backlog items) moved into Sprint backlog and estimated in numbers, instead "T shirt sizes", it means that you are using story points now

And this is a moment when the risk of forgetting the actual origin of this number kicks in. People naturally tend to associate the mathematical numbers with exact measures.  So, driven by the misconception that numbers should correspond with metrics,  managers, CEO or even Scrum practitioners who don't understand the origin of story points begin to presume that story point numbers somehow represent the performance and result.

Unfortunate use of term "velocity", which is NOT SAME as velocity in physics makes a confusion even worse.

Eventually it causes problems in both, team transparency and inspection of results: by bringing misleading and false metrics(which are not actually metrics).

So it is very important to remember that estimates are not a measure of teams actual performance in any way: because, of course it would be absurd to measure teams result based on teams own predictions - which are in fact hunches, not even calculated forecasts. Its  would be a same thing like estimating days activity based on weather prediction made purely on folk omens.

Having said that, may be next edition of Scrum guide should contain some strong provision preventing use of estimates as the metrics for counting the results of the Scrum teams work during the sprint . And also stating that the value of increment is one and only aspect which is establishing commitment and result of the team.

Otherwise the story pointing issue will east Scrum within like a cancer

In my understanding, a Scrum team of 20 will have a different story points count than a team of 10, or can they be the same?

There are guidelines on how to assign story points, but two teams are not guaranteed to assign the same story points to the same backlog item. (If they asked to do so.)

One team can assign 13 and another team can assign 8, and both teams may complete the item in one week as an example. The one team can be twice as large as the other, it does not matter how the story points are assigned.

The main thing is only that a team sizes similar items consistently. For one team an 8 is roughly of a certain size and complexity and the aim is that all 8's this team assign should be of similar size and complexity.  (Sure sizing is going to be off at times as it is only an estimate, but that is the aim.)