Finding out the velocity of the team

 in the last 3 sprint completed 10, 12 and 12 user stories, the velocity of the team will be around 11.

What you described resonates well with the so called "no estimates" approach, which assumes that all tasks / stories are more or less equal. Whether this is correct or not (and in what circumstances) is a separate discussion. If your team's decision is that due to your context you actually need more details to estimations, then a typical approach could be to, for example, assign so called story points to each story first, and then calculate the velocity as a sum of all story point estimations of all stories done during a sprint.

Strictly speaking this measure is the throughput of work Done, rather than velocity in the usually accepted sense. Velocity typically refers to the completion of work items as measured by their estimated size, which can of course vary.

Throughput is a useful metric which has the advantage of being an empirical measure of work Done, and one for which there is no estimation overhead. However it can drive a more fine-grained approach to refinement so items are roughly of even size, and this may not be appropriate for the meaningful delivery of value in certain circumstances.

So in order to explain management how can we provide estimate times, i plan to explain them using the velocity factor and that depending on the amount of user stories on the backlog and the velocity of the team

I know you didn't ask specifically about this, but a couple of things you might want to consider when forecasting to management.

1. I would advise being cautious with the way you use velocity or throughput; particularly with those outside of the Scrum Team. I once made the mistake of showing off this 'cool story point thing' we were trying out, and velocity then became a way of deciding whether the team were doing a good job or not. That's a whole discussion of its own, but do be aware that velocity is commonly abused in such a way, and it can be very harmful.
   
   I have no experience of doing this with throughput. It might not cause the same problems, but do tread carefully.
   
    
2. If you are giving forecasts, you might want to convey the element of risk. Because no forecast can ever be 100% certain. I'll try to explain why, but it's quite mathematical, so I'm not sure how clear I can make it.

If your milestone is reached by completing 42 stories, and your throughput is 11 on average, all you can say is it'll probably take 4 sprints to reach that milestone; but you have no idea whether you will get unlucky, and have a series of relatively unsuccessful sprints, causing it to take longer.

You have a small data sample so far, but based on your past outcomes, ⅓ of your sprints have a throughput of 10, and ⅔ have a throughput of 12.

So there is a (small) chance that based on historical data, the milestone won't be reached in 4 sprints. If you have a bad run, and you get 4 consecutive sprints with a throughput of 10, it will actually take 5 sprints to reach the milestone.

Based on your data, the chance of this happening is ⅓ x ⅓ x ⅓ x ⅓ = 1 in 81.

This would mean that there is an 80 in 81 (98.8%) chance of you meeting the milestone within 4 sprints.

So rather than just predicting 4 sprints, you could communicate that there is a 98.8% chance of meeting the milestone inside 4 sprints, allowing space for other empirically possible outcomes.

Once you have more throughput data, the forecasts should become much more reliable, but also vastly more difficult to calculate, and you may wish to investigate something called the Monte Carlo method.