If you combine this:
My goal is ready to use application for employers and employees. [...] The bad thing is that i have ten days to finish this application.
with this:
We use something based on scrum, making everything in system as needed of working time evidence.
then it's quite clear, that you have just one run. No sprints, no Scrum. Another matter, if you are generally using scrum and want to use it for the project. In this particular case, I would advise against it, and I'll explain it later.
If you combine this:
We have 20 user stories from our project managers and we have to achieve implementation of this goals.
with this:
We all are new to [...] technology and we have to do this in [...]
and add this on top:
I assume one functionality takes 3-4 days to implement. So calculating makes us 6 functionalities, and five is completed.
then it's also quite clear, that you cannot achieve the goal of "completing everything". One can say, that it is highly improbable, however upsetting this may be.
Also, you should avoid assumptions and try to do rough estimates upfront. In such a short time frame, wrong assumptions can be devastating.
How to complete goal in this circumstances, which is completed application? Is it possible? [...] if we assume that not - should we trim user stories for most important?
Your resources and time are limited. Hence your best option is to reduce the scope. While there are a couple of ways of doing that, combining them may give you better results:
- Define a minimum viable product. Literally cut off everything that is not mission critical. You can come back and revisit those parts later, after your deadline.
- Get a person, who is capable of prioritizing stories from the end user perspective, and arrange them in order of decreasing value.
- Start working on the stories from the top to the bottom.
What will happen in the end is you will, likely, not do everything. At the same time, you would have built a valuable "demo", or a part of the final system, which will at least be usable.
What matters in this case is progress tracking. Kanban will be the simplest way to do that, considering the small team and short timeframes. Make a goal of pushing stories through one by one: dev-test-done, as a production line. Preferable testing will start as soon as the first story is completed.
You may also want to sacrifice some quality, thus testing only the main paths and making sure other ones do not damage the data (it is probably OK if they don't fully work anyway).