There is a baked in supposition that you must do all 500 points of scope in order to meet the user's needs. In Scrum, the first thing we would do is to challenge this assumption. By focusing on meeting needs rather than doing work, we can often find simpler solutions or identify things that aren't really needed.
Now, there are two other questions in here:
- How can a team get faster?
- How do I go faster than a team can go?
For helping the team go faster, the team should be having a retrospective and looking for improvements each sprint. However, any way of working reaches a peak level of efficiency and you have to change approaches of work to get more speed out of the team. This is great, but it is also dangerous. Any change to the way of working will slow the team down while they are adapting to it and it's possible that they won't get it right the first time (or second). This should be done at a time when teams can absorb a slow-down in order to gain improved speed later.
We can also add teams. Adding people to a project is complex. You would think that if one team was completing 50 points, two would complete 100, but they won't. They have overhead of working together, not to mention that there is a ramp-up time and will slow down the other team during that period. Again, this does have to be done carefully.