Velocity and Calculation for launching a Product in a crossfunctional Team

A few things stand out to me.

You don't need velocity calculations to determine your capacity for a Sprint. Personally, I would strongly recommend against the use of velocity, especially if you are sizing in story points, which is something else that I'd recommend. Focusing on right-sizing the Product Backlog Items to the smallest deliverable (or demonstrable) units of work and counting the completion rate tends to give more than enough for planning. Tracking cycle time and throughput can be used for longer-term forecasting. If the team feels the need to estimate, estimating ideal hours can be useful, and if you track cycle time, you have the actual clock time and can get some figures around how much of the team's time is spent on value-adding work. The only time you may need a "gut feeling" is your first Sprint and when you're counting stories. If you're estimating in ideal hours, there are some broad estimates across organizations and industries for the ratio of working hours to productive hours that you can use until you have team-specific data.

Now, moving to the long-term roadmap, I'd be curious as to why this is necessary. If you're using agile methods, you should have accepted the fact that you do not know all the requirements and you cannot know all the requirements at the start. As you do the work, you may discover some things that need to be part of your MVP. You may also discover some work that can be deferred to later or isn't necessary at all. Your Product Backlog will change. On top of this, you have no (or little) data about the team's rate of completing work (in the form of velocity, or ideally throughput) that you can use to forecast short-range and mid-range plans based on the state of the Product Backlog today. Scrum addresses this risk by making progress visible - your key stakeholders should be able to see progress in the form of working product at least once per Sprint and deliver feedback and plan next steps with the Scrum Team at the Sprint Review.

Regardless of if you estimate or not or long-term forecast or not, the final piece is the "frontend story" and "non frontend story". These things shouldn't exist. A Product Backlog Item represents something that is valuable to users or stakeholders. In most cases, multiple aspects or layers of the product will need to be modified to deliver that value. This is commonly expressed as preferring vertical slices over horizontal slices. Developing cross-functional individuals who are capable of working outside of their area of specialty to delivery value. You may have experts in frontend development, backend development, or mobile development, but it tends to be helpful to have mobile developers who understand and can help with frontend or backend development, for example, and contribute to refining and slicing work that may not involve their area of expertise.

But what if there is a worst case scenario?

There may be a better case scenario for that matter. The point is you don't know.

So how can we now establish a velocity that would maybe help us? Would it help us is the other question?

Whatever velocity you establish, you can't expect it to be entirely accurate. When you say that something is likely to be delivered in August, that is a rough time-frame precisely stated. It might reasonably perhaps be one month either way.

So, when you observe what the velocity is -- and make a forecast on that basis -- it might be wise to give a probability and a range with it. As the Developers get better at estimation and velocity stabilizes, the probability of a forecast being accurate increases and the range is likely to narrow.

And why I am also asking is, if we want to establish a velocity and do for example planning poker how can the guys from the frontend estimate a non frontend story because they have no clue about the scope of the story?

There's your problem. A user story is a placeholder for a conversation about a potential requirement. The value lies in the conversation that is to be had between Developers with different skills and perspectives -- programmers, testers, designers and so on. Through those conversations, Developers can develop a consensus view of reality and hold themselves jointly accountable for the work they collectively take on and complete.

In the scenario you describe, that value has been stripped away, and accountability diminishes. Instead, it seems you have fake stories that represent technical work for people with certain skill silos. That's the problem to solve.