I think you're looking at it a bit backwards. Velocity is an after-effect of the work your team is doing. It is not a causal factor - ie. it's something you measure and it's not something you can directly tweak.
This explanation of velocity has a relevant tidbit to your question.
The simplest way to define velocity is: the number or user stories a team/project can do in one sprint
And by that definition, a longer sprint means more time for development per sprint and therefore a greater velocity number.
Relative velocity between a 2 week or a 3 week sprint is a slightly different question. Overhead from project ceremonies can impact how much you can get done because there is less overall time available. Consider this calculation as a way to identify available development hours in a sprint.
DevHoursAvailable = ((HoursInDay * DaysInSprint) - CeremonyOverhead) * AvailabilityFactor * NumberOfDevs
CeremonyOverhead
is generally fixed. Decrease your DaysInSprint
and you can see how you'll have less available time for development during that sprint. Using a simple example of 1 dev, here are the numbers for a few sprint lengths.
1 week:
((8 * 5) - 4) *.8 = 28.8 hours or 5.76 hours per day.
2 weeks:
((8 * 10) - 4) *.8 = 60.8 hours or 6.08 hours per day.
3 weeks:
((8 * 15) - 4) *.8 = 92.8 hours or 6.18 hours per day.
The "obvious" answer is that longer sprints are better. The problem with the obvious answer is that it ignores the beneficial impact of feedback loops. Temper thoughts regarding that calculation with an overall perspective on what Agile is supposed to bring to the development process.
I suspect your core issue is that your user stories are not as defined as they could be. That lack of understanding what's required is the real impediment to getting work accomplished.